Bugs item #445910, was opened at 2001-07-30 04:07
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=445910&group_id=4664
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: getting segmentation failure
Initial Comment:
Hi,
I tried to build the cscope-15.3 for solaris.
I followed the steps given in INSTALL file.
But when I goto 'src' directory and try to execute
cscope, getting segmentaion fault and core dumped.
Can we change the path of 'prefex' to a user home directory
rather than 'usr/local'?. The thing is I don't want to build cscope
as a root. Want to build under my home directory.
So, please suggest me to over come this problem.
Thanks,
Aravinda
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2001-07-30 05:10
Message:
Logged In: NO
I got 'ocs' in bin directory. Executed it and got following error.
exec cscope
cscope: Cannot find /lib/ld-linux.so.2
Killed
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=445910&group_id=4664

Bugs item #445910, was opened at 2001-07-30 04:07
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=445910&group_id=4664
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: getting segmentation failure
Initial Comment:
Hi,
I tried to build the cscope-15.3 for solaris.
I followed the steps given in INSTALL file.
But when I goto 'src' directory and try to execute
cscope, getting segmentaion fault and core dumped.
Can we change the path of 'prefex' to a user home directory
rather than 'usr/local'?. The thing is I don't want to build cscope
as a root. Want to build under my home directory.
So, please suggest me to over come this problem.
Thanks,
Aravinda
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=445910&group_id=4664

Bugs item #229144, was opened at 2001-01-17 08:08
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=229144&group_id=4664
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Petr Sorfa (petr)
Summary: Build failed on Solaris. Symbol 'yywrap' unresolved.
Initial Comment:
Make failed with linker unable to find symbol "yywrap" in file scanner.c.
Running Solaris 5.6 with user install of flex. Tar of cscope v15.1.
Make summary:
./configure --with-flex --prefix=/home/myuserid/usr-solaris
make clean
make
Work around by copying my local 'libfl.a' library to the cscope-15.1/src directory. Changing 'LEXLIB=' line to 'LEXLIB=libfl.a' Compile passed and first uses of cscope works.
Apparently my libfl.a could not be found during configure process and I didn't know how to specify directly.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2001-07-28 12:03
Message:
Logged In: NO
I experienced a similar problem while building 15.3 on
Mac OS X 10.0.4.
The OS includes both flex and lex, but only libl.a.
Configure finds flex first, and so only checks for yywrap
in libfl.a, but doesn't try looking for libl.a if that test fails.
----------------------------------------------------------------------
Comment By: Petr Sorfa (petr)
Date: 2001-01-23 07:41
Message:
Seems like a config problem. Will have a closer look.
Petr
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=229144&group_id=4664

Bugs item #206950, was opened at 2000-06-05 09:55
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=206950&group_id=4664
Category: None
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Hans-Bernhard Broeker (broeker)
Summary: crashes after being suspended
Initial Comment:
when trying to fg after being suspended, cscope dies.
Cscope version 15.0bl2
OSF1 V4.0 alpha
----------------------------------------------------------------------
>Comment By: Hans-Bernhard Broeker (broeker)
Date: 2001-07-12 05:57
Message:
Logged In: YES
user_id=27517
I've found some time to check whether my impression that
this was a curses-related problem actually holds --- and it
does. On a Digital Unix Alpha box, the problem went away as
I moved to NCurses instead of /usr/lib/curses. I'll put a
paragraph about this into the INSTALL document.
----------------------------------------------------------------------
Comment By: Ali Bahar (ouipapa)
Date: 2001-05-11 19:12
Message:
Logged In: YES
user_id=33103
I used to see this very often on Sun Solaris (2.7) machines.
Highly reproducible in my environment, and not at all
infrequent. Unfortunately, I did not get a chance to work on
it (been running around 3 countries over the last year), and
I no longer have access to Suns.
It's fine (15.0b12, and 15.1) on x86 Linux, though. I
suspend cscope very often, and it resumes itself nicely. By
contrast, on the Sun Solaris boxes, it would die as soon as
I'd run the 'fg'.
----------------------------------------------------------------------
Comment By: Hans-Bernhard Broeker (broeker)
Date: 2000-10-31 04:17
Message:
Seems like the problem is with the 'curses' library. At least, it does not occur if cscope is running in line mode (-l), with no curses involved. And the crash backtrace also points into the direction of
the curses wgetch() function, roughly.
----------------------------------------------------------------------
Comment By: Hans-Bernhard Broeker (broeker)
Date: 2000-07-11 07:00
Message:
Reproducible with latest version on Alpha box, but not on i386 Linux.
I tried to debug this, but gdb doesn't seem to want to let me trace into
cscope again once I've interrupted the debuggee with ^Z :-(
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=206950&group_id=4664

Bugs item #434309, was opened at 2001-06-18 15:09
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=434309&group_id=4664
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Petr Sorfa (petr)
Summary: Infinite loop in scan_dir()
Initial Comment:
When cscope is invoked recursively to process a source
tree, a symlink which points to the current directory
(e.g. `ln -s . symlink') will cause scan_dir() to go
into an infinite loop.
The fix is to change the call to stat() with a call to
lstat(). You may need to check for existence of lstat
in configure.in.
----------------------------------------------------------------------
>Comment By: Petr Sorfa (petr)
Date: 2001-07-09 08:03
Message:
Logged In: YES
user_id=26835
Fixed. I used a more generic fix than that provided by the
submitted patch. Thanks.
----------------------------------------------------------------------
Comment By: Hans-Bernhard Broeker (broeker)
Date: 2001-06-19 06:54
Message:
Logged In: YES
user_id=27517
I don't think it's as simple as that. It still would fail if
you created a
cycle of more than one directory, as in:
cd /tmp
mkdir a
mkdir a/b
ln -s ../.. a/b/c
which has /tmp/a/b/c point back to /tmp/a.
Nor will the loop truly be infinite, on any sane OS ---
sooner or later the fixed limit on number of nesting levels
of symlinks would strike back.
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=434309&group_id=4664

On Fri, Jul 06, 2001 at 11:47:24AM +0200, Hans-Bernhard Broeker wrote:
> You open the bug, and select 'Closed' from the chooser box that read
> "Open" before. You may have to be raised to "Bug technician" privileges
> by Petr to be allowed to do that.
Thanks. I think that's the problem: I don't have the privileges (I
never see any chooser box). Petr?
-- Darryl

Hi, all,
just so you all know, the next thing I'm going to do is rip build() and
all related subfunctions (roughly half of it) out of main.c into a
new separate source module, 'build.c'. The editing is done, already,
but CVS doesn't seem to work, at this time, otherwise I'ld have checked
this in already...
--
Hans-Bernhard Broeker (broeker@...)
Even if all the snow were burnt, ashes would remain.

On Thu, 5 Jul 2001, Darlene Wong wrote:
> Whenever I attempt to build the cscope database, I get this error
> "input in flex scanner failed". Have you ever received this error?
No, I don't think I ever have.
> What should I do to try to fix flex?
Nothing, I think --- it's not flex that's broken, I assume.
But a few more details would be handy, such as:
Is cscope configured for using 'flex' instead of 'lex'? Please double
check your src/Makefile: it should have the LEXER_SOURCE=scanner.l
commented out, and the fscanner.l one commented in, and 'make' should
actually be calling 'flex'.
Other possibly vital information would be:
1) platform
2) compiler
3) The source code you're running cscope on.
--
Hans-Bernhard Broeker (broeker@...)
Even if all the snow were burnt, ashes would remain.

On Thu, 5 Jul 2001, Darryl Okahata wrote:
> This may be a stupid question, but how does one close bugs/patches
> (the ones listed on sourceforge)? I've looked through the sourceforge
> docs, and searched the help forums, but I can't find anything.
You open the bug, and select 'Closed' from the chooser box that read
"Open" before. You may have to be raised to "Bug technician" privileges
by Petr to be allowed to do that.
--
Hans-Bernhard Broeker (broeker@...)
Even if all the snow were burnt, ashes would remain.

This may be a stupid question, but how does one close bugs/patches
(the ones listed on sourceforge)? I've looked through the sourceforge
docs, and searched the help forums, but I can't find anything.
Thanks,
-- Darryl

Hi,
Whenever I attempt to build the cscope database, I get this error
"input in flex scanner failed". Have you ever received this error? What should I do to try to fix flex? I am using cscope 15.3, flex 2.5.4, and running cscope with the -b -c options. Thanks a million!
Darlene

Bugs item #208551, was opened at 2000-06-28 18:59
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=208551&group_id=4664
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Andy Newman (atrn)
Assigned to: Hans-Bernhard Broeker (broeker)
Summary: Handling of -d switch broken
Initial Comment:
If you try to load an existing database without
building it, i.e, use the -d switch, cscope exits.
It is unable to parse the cross-reference file.
Try this in line mode (so the UI doesn't get in
the way) and you receive the message,
cscope: cannot read list size from file cscope.out
Has bad affects with cbrowser :(
Platform: FreeBSD 4.0-STABLE
----------------------------------------------------------------------
>Comment By: Hans-Bernhard Broeker (broeker)
Date: 2001-07-05 07:45
Message:
Logged In: YES
user_id=27517
I've checked in changes that should fix most, maybe all of
these, for good. dbfputs() now always uses strlen() instead
of looking at the return value of fputs(), and the ftell()
calls are #ifdef'ed upon a telltale macro
PRINTF_RETVAL_BROKEN, instead of checking for particular
platform #defines. I'm closing this report.
----------------------------------------------------------------------
Comment By: Steven Elliott (selliott4)
Date: 2001-06-22 00:14
Message:
Logged In: YES
user_id=77630
If the -d switch is still not working on your platform you
might want to try patch #435355. It fixes the -d switch for
at least Windows NT 4.X + cygwin 1.1.8.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2000-12-07 12:37
Message:
Re: the person reporting problems under cygwin-NT
Cygwin defaults to the wrong version of the
dbfputs macro. Modify the source to compile
with the version which uses strlen to maintain
dboffset and you should be fine.
----------------------------------------------------------------------
Comment By: Andy Newman (atrn)
Date: 2000-11-01 14:01
Message:
All modern BSD systems (since 4.4) have ANSI C libraries. fputs() doesn't return the count of characters written so
BSD shouldn't be using it. The code is old and back then
BSD had a, let's be polite, unique view of the C library.
At least different to the east coast people. Hence all
the USG vs. BSD #ifdefs in places. A lot of those #ifdefs
didn't get changed now that 4.4BSD is more common).
Anyway thanks to all for helping fix it. Didn't think
it would cause so much bother.
----------------------------------------------------------------------
Comment By: Hans-Bernhard Broeker (broeker)
Date: 2000-10-27 05:53
Message:
After checking in the relevant fix, I think this should now be handled correctly.
Regarding the dbfputs() stuff: Should FreeBSD have been using the version of that macro which assumes that fputs() returns the number of chars written, in the first place? Doesn't it #define BSD 1?
----------------------------------------------------------------------
Comment By: Andy Newman (atrn)
Date: 2000-08-11 04:40
Message:
Now that some else has reported this I did a little
digging. The test case is cscope's source. Step 1
is to build the database "cscope -b" in cscope/src
directory. Then try "cscope -d -l". The header has
a wrong seek position for the include/source file lists
in the file. In my test case the header says the first
list is at offset 381880 but its actually at 383083
(in my test case, it'll be different elsewhere of course).
The first call to skiplist() trys to read the count
of the number of lines and fails - the next getc() will
read from the wrong position (right in the middle of what
looks like a cross reference entry in my case). So it's
off to check out how the database gets built...
A quick scan shows that dboffset is not correct
when it is assigned to traileroffset in build()
(main.c:1011). Hmm....dboffset and ftell(newrefs)
are out of sync...Use a smaller test and whammo...
In putfilename() at the invoccation of the dbfputs
macro. A quick look at it....
dbfputs is wrong. fputs() returns 0 on success
on this platform (FreeBSD) as it should. So dboffset
doesn't get incremented by the length of the filename
just written. I've fixed mine version.
I'll send a patch that fixes this and also fixes
the case when you run with -d and there are no
source files - srcfiles is NULL in this case and
the exit code was assuming it wasn't and dumping
core.
----------------------------------------------------------------------
Comment By: Jerry Iseri (jiseri)
Date: 2000-08-10 10:32
Message:
PLATFROM: CYGWIN_NT-4.0
I have the same problem using the cygwin environment
on Windows NT 4.0. Not sure what the format of the
database is, without spending too much time on it.
But even a small test like:
main()
{
int a;
}
has the same problem when "cscope -d" is used.
If you just type "cscope" things are okay.
----------------------------------------------------------------------
Comment By: Petr Sorfa (petr)
Date: 2000-07-10 14:25
Message:
Sorry if I'm repeating myself. Latest code in CVS should solve this problem.
----------------------------------------------------------------------
Comment By: Petr Sorfa (petr)
Date: 2000-07-10 13:47
Message:
Broeker is right, we need some more info. Try downloading the CVS
source and try it with that if you aren't already
----------------------------------------------------------------------
Comment By: Hans-Bernhard Broeker (broeker)
Date: 2000-07-10 12:32
Message:
Tried the given sequence --- still no success reproducing buggy
behaviour.
It may be necessary for you to mail your cscope.out file to someone
for cross-checking...
My guess would be it's some platform-specific details that cscope
doesn't anticipate. Hard or impossible to debug from remote.
----------------------------------------------------------------------
Comment By: Andy Newman (atrn)
Date: 2000-07-07 12:50
Message:
For me the following sequence works...
$ touch junk.c
$ cscope -b junk.c
$ cscope -d -l junk.c
cscope: cannot read list size from file cscope.out
$
I had a quick look the other day to see if it was something
simple but it isn't. It appears the database is organised as
a number of "chunks", each having a size. The message is
about it not being able to parse the size header from one
of the junks. It seeks to the start of the chunk and uses
scanf to read the size. It fails. I haven't traced through it
any more and haven't bothered to check the details of the
file format (sorry I'm not beng more helpful but I've got my
own bugs to fix too :) Could be in the area of stdio setpos
implementation spefics or similar.
----------------------------------------------------------------------
Comment By: Hans-Bernhard Broeker (broeker)
Date: 2000-07-07 08:41
Message:
I think we'll need more details. A precise sequence of cscope
invocations with all the flags, and maybe an idea what size of
source base you're talking about.
I couldn't seem to reproduce the problem here, on a Digital Unix 4.0
box, no matter how hard I tried.
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=208551&group_id=4664

Bugs item #424198, was opened at 2001-05-15 02:44
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=424198&group_id=4664
Category: None
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Hans-Bernhard Broeker (broeker)
Summary: not a bug more of a porting problem
Initial Comment:
Hi
I'm attempting to compile cscope 15.1 on HP-UX 10.20 or 11.00 or SunOS 5.6 or 5.8. I get the
same messages with configure and the same errors on all platforms.
I am running configure with the following set to local destinations:-
--prefix=<path>
--exec-prefix=<path>
--with-flex=<path>
--with-bison=<path>
--with-ncurses=<path>
Where <path> is the path to the directory required, I checked this in the Makefile after.
Things i have tred so so in various combinations;
HP-UX's ANSI comipler cc, gcc 2.8.1 and gcc 2.95.2, with HP's lex and yacc rather than Flex and
bison.
SunOS gcc 2.8.1 and gcc 2.95.2, with flex and bison only.
during the configure stage on all platforms I get the following lines that may be of importance
checking for flex... (cached) flex
checking for yywrap in -lfl... (cached) no
checking lex output file root... (cached) lex.yy
checking whether yytext is a pointer... (cached) no
checking for bison... (cached) bison -y
and from the compiler out put
gcc -g -O2 -o cscope scanner.o egrep.o alloc.o basename.o command.o compath.o crossref.o
dir.o display.o edit.o exec.o find.o help.o history.o input.o invlib.o logdir.o lookup.o main.o mouse.o
mygetenv.o mypopen.o vpaccess.o vpfopen.o vpinit.o vpopen.o
-L/users/contrib/pkgs/ncurses/ncurses-4.2/SunOS/5.6/lib -lncurses
Undefined first referenced
symbol in file
yywrap scanner.o
ld: fatal: Symbol referencing errors. No output written to cscope
*** Error code 1
make: Fatal error: Command failed for target `cscope'
Current working directory /users/contrib/pkgs/cscope/dist/cscope-15.1/src
*** Error code 1
make: Fatal error: Command failed for target `all-recursive'
Current working directory /users/contrib/pkgs/cscope/dist/cscope-15.1
*** Error code 1
make: Fatal error: Command failed for target `all-recursive-am'
I am running 'make distclean' between attempts to clear out the shrapnel left over and yes when I
tryied to use the HP versions of lex and yacc I did add the configure switches --with-lex and
--with-yacc
I read the readme and install files :-) not much info in those.
btw. There does not seem to bew a way to specify the location of include header files for ncurses
as they are assumed to have the same base as the lib files. :-)
Thanks in advance
Richard.
ps. could not login to sourceforge with Netscape as it kept timimg out.
----------------------------------------------------------------------
Comment By: Hans-Bernhard Broeker (broeker)
Date: 2001-05-25 05:21
Message:
Logged In: YES
user_id=27517
The key problem with your flex usage, I think, is that you
don't have libfl.a installed in a place where the linker
(and thus 'configure') can find it. That's essentially a
flex installation problem, IMHO.
You don't have to hack the Makefile or copy libfl.a, though.
Just run
make LEXLIB=/wher/ever/it/is/libfl.a
With a similar override, you can make your ncurses.h header
visible
to the compiler. Just override the CPPFLAGS to add an
'-I/my/ncurses' option.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-15 03:14
Message:
Logged In: NO
oops, ok now I've read the other posting I find the answer
so that's what traker is :-)
Answer is copy your flex library liblf.a to the src
directory
hack the Makefile in the src directory to Set LEXLIB=liblf.a
make
and it worked with gcc 2.8.1.
bye for now
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=424198&group_id=4664

Hi All,
First of all, thanks to everybody that made 15.3 possible. Well done! We
did a great job particularly due to the efforts of Hans-Bernhard and
Darryl.
I've updated the TOT to version 16.0a which will be the next release.
So the tree is unfrozen, and go ahead and commit when you wish.
Petr
--
--------------------------------------------------------
Petr Sorfa Senior Software Engineer
Caldera
430 Mountain Ave. http://www.caldera.com
Murray Hill 07974
NJ, USA
--------------------------------------------------------
Disclaimer: All my comments are my own and nobody else's
----------------------------------------------------------