[Cscope-devel] [ cscope-Bugs-630442 ] Solaris-Intel fails with vendor's curses library

[<no...@so...>]

Bugs item #630442, was opened at 2002-10-29 14:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104664&aid=630442&group_id=4664

Category: Curses interface
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Sarnath Kannan (abcdz)
Assigned to: Hans-Bernhard Broeker (broeker)
>Summary: Solaris-Intel fails with vendor's curses library

Initial Comment:
Hi,
 I downloaded the CSCOPE sources (15.4, 15.3, 15.1, 
13.xx.. I tried with each one of them..)
 and compiled it on  an INTEL based SOlaris box V 2.8.
 I used flex and bison (GNU version) . While 
 compiling, "bison" says "2 shift-reduce conflict" in   
 src/egrep.y
 However the compilation continues and I get the final
 executable. The cscope, so built , is very unsteady and 
 core-dumps on even very moderately big search. (I 
 used "find global definition"). Sometimes it crashes even 
 while building the database. This is not
 consistent also. When it  crashes while building, the 
 "percentage complete" varies.
 For exp, sometimes it is 70 out of 101.. Sometimes it is 90
 etc..
 Is CSCOPE un-runnable on Solaris, Intel 
 based versions ?
 A Sample DUMP anatomy :(On version 15.4 when 
CSCOPE crashed while building database):

"
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public 
License, and you are
welcome to change it and/or distribute copies of it under 
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show 
warranty" for details.
This GDB was configured as "i386-pc-solaris2.8".
Core was generated by `cscope'.
Program terminated with signal 11, Segmentation Fault.
#0  0x0 in ?? ()
(gdb) symbol-file cscope
Reading symbols from cscope...done.
(gdb) bt
#0  0x0 in ?? ()
#1  0xdfb8723c in ?? ()
#2  0xdfb7bedf in ?? ()
#3  0x805d6d1 in progress (what=0x8095a57 <Address 
0x8095a57 out of bounds>,
    current=70, max=101) at display.c:575
#4  0x8058504 in build () at build.c:369
#5  0x8062be0 in main (argc=0, argv=0x8047c98) at 
main.c:525
(gdb)
"

Thanks for any help
-
Sarnath

----------------------------------------------------------------------

>Comment By: Hans-Bernhard Broeker (broeker)
Date: 2002-10-30 17:12

Message:
Logged In: YES 
user_id=27517

That LD_LIBRARY_PATH stuff wouldn't be necessary if you
really had linked to libncurses.a.  It's rather a
consequence of installing a .so type shared library in a
place outside of the runtime linker's default search path.
The remedy is to (manually) add '-R/opt/sfw/lib' to the link
command line (make LDFLAGS="-R/opt/sfw/lib" should do it).

Anyway: I consider this settled.  I'll add a comment to the
INSTALL document and close this.

----------------------------------------------------------------------

Comment By: Sarnath Kannan (abcdz)
Date: 2002-10-30 06:46

Message:
Logged In: YES 
user_id=588588

Hi Broeker,

 You were exactly right. Thanks a lot for ur suggestion.
 I will just mention the following steps so that it might be 
 useful for some one who comes across the same 
 problem.

1.
Configured "cscope" for "ncurses"
 (./configure --with-flex --with-bison --with-
ncurses=/opt/sfw. )
 The ncurses lib in my  machine is in /opt/sfw/lib

2. make 

3. "make install" as "root".

4.
 LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/sfw/lib
 export LD_LIBRARY_PATH
 This step is required if u r using GNU LD. For other
 linkers, you need to specify the path to libnucrses.a 
 according to how the linker expects. Otherwise
 create links to libncurses.a from one of the standard
 Library paths.
 
3. execute cscope.


----------------------------------------------------------------------

Comment By: Hans-Bernhard Broeker (broeker)
Date: 2002-10-29 14:56

Message:
Logged In: YES 
user_id=27517

This almost certainly is a bug not in the scanner, but in
the curses-based user-interface.  The fact that the
cscope-internal part of the backtrace ends in the progress()
function makes that quite obvious. The two addresses in the
0xdfb... range are almost certainly inside the curses
library.

Can you please verify this by repeating your tests in line
mode, i.e. using
the '-l' flag?

If possible, please try another curses implementation
(ncurses instead of Solaris' own, e.g.)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104664&aid=630442&group_id=4664