Dear GDB team (and Mr. Psarogiannakopoulos):
I use gdb version 4.18 under Linux version 2.2.13 to debug a
commercial C++ program compiled with gcc version 2.95.1.
The program is 'organized' into 22 modules, and we build a shared
library from each module. I make no claim that great thought has gone
into this organization and cyclic dependencies surely exist. However,
the program links and runs correctly and is debuggable on several
other platforms (e.g. IRIX, SunOS), using debuggers native to those
platforms.
I have had great difficulty using gdb on my program and I am bombarded
with messages from gdb like
Cannot insert breakpoint 1:
Cannot access memory at address 0x4001f4fc.
I have finally become convinced that the problem is related to my use
of shared libraries. To make a case for this, I have created two
executables, one using my standard scheme, the other built directly
from object files, skipping the intermediated shared libraries.
The following sessions illustrate the problem I am having.
% gdb -q -tty /dev/null from_so
(gdb) break main
Breakpoint 1 at 0x804b304
(gdb) run test
Starting program: /home/gisli/from_so ttcs/bigspdp
Breakpoint 1 at 0x4001f4fc: file
/home/gisli/Main.cxx, line 244.
Breakpoint 1, 0x4001f4fc in main ()
at /home/gisli/Main.cxx:244
244 }
Current language: auto; currently c++
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/gisli/from_so test
Cannot insert breakpoint 1:
Cannot access memory at address 0x4001f4fc.
(gdb)
The program is totally un-debuggable. Meanwhile, applying gdb to the
executable that does not make use of shared objects results in the
following session:
% gdb -q -tty /dev/null from_o
(gdb) break main
Breakpoint 1 at 0x82af71c: file
/home/gisli/Main.cxx, line 101.
(gdb) run test
Starting program: /home/gisli/from_o test
Breakpoint 1, main (argc=2, argv=0xbffff284)
at /home/gisli/Main.cxx:101
101 int ok = 1;
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/gisli/from_o test
Breakpoint 1, main (argc=2, argv=0xbffff284)
at /home/gisli/Main.cxx:101
101 int ok = 1;
(gdb)
In this session gdb works as advertised.
Finally, in case it provides additional insight, I tried to repeat
the first session with the -r flag, in case it might help gdb to read
the symbol table immediately. Unexpectedly, gdb started just as
fast in the first case, but failed to stop at the breakpoint, due
to running out of virtual memory (of which I have about 400Mb).
% gdb -r -q -tty /dev/null from_so
(gdb) break main
Breakpoint 1 at 0x804b304
(gdb) run test
Starting program: /home/gisli/from_so test
Breakpoint 1 at 0x4001f4fc: file
/home/gisli/Main.cxx, line 244.
gdb: virtual memory exhausted: can't allocate 5369226 bytes.
Please note that in the first session gdb initially fails to associate
the breakpoint with a source line (I suspect that this may be expected
when using shared objects and gdb loads minimal information) but when
it stops in main, it believes it should be at source line 244, which
is wrong. The second session gets it right placing main in line 101.
I am aware that this is an extremely weak bug report. I have not been
able to recreate this in a simple program and I will not be permitted
to send you my source (nor do I think you would want this). What I
can do is to place myself at your disposal to perform any kind of
analysis of the problem you think I can.
A quick survey of the web revealed one report of a similar problem. I
am taking the liberty of referencing this message and CCing the
gentleman who made the report, in case this may shed additional light.
Perhaps mozilla could be used to replicate my problem. The report is
at http://sourceware.cygnus.com/ml/gdb/1999-q4/msg00530.html
Thanks for your attention
Gisli Ottarsson
Ann Arbor, MI
