Can gdb debug a core file (or not)?

Can gdb debug a core file (or not)? (Full Version)

All Forums >> [SFU / Interix / SUA Technology] >> Interix Advanced Forum

Message

jon493 -> Can gdb debug a core file (or not)? (Nov. 15, '05, 3:35:28 AM)
In use: The gdb, gcc supplied with SFU I wrote a simple C application that caused an Access Violation (Segmentation Fault for the Windowsly challenged). So I plopped the core file into gdb and the following ensued: GNU gdb 2002-11-11-cvs Copyright 2002 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 "i586-pc-interix3"... /dev/fs/C/gnu2.intel/egcs.source/gdb/coffread.c:830: internal-error: sect_index_text not initialized A problem internal to GDB has been detected. Further debugging may prove unreliable. Quit this debugging session? (y or n) y Create a core file of GDB? (y or n) y So now I gdb'd the gdb core file: GNU gdb 2002-11-11-cvs Copyright 2002 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 "i586-pc-interix3"... /dev/fs/C/gnu2.intel/egcs.source/gdb/coffread.c:830: internal-error: sect_index_text not initialized A problem internal to GDB has been detected. Further debugging may prove unreliable. Quit this debugging session? (y or n) y Create a core file of GDB? (y or n) n Amazing isn't it? It seems to be happening no matter what core file I feed it. Even on a Pentium III ! Regular debugging is just fine: it just chokes on core files.

Rodney -> RE: Can gdb debug a core file (or not)? (Nov. 15, '05, 5:54:38 AM)
I've used gdb on core files many times. The caveat is that the core files need to be generated for a gcc built binary. But what is happening in this case I'm not really sure. We'd have to know what the file is to try and analyse it out.

jon493 -> RE: Can gdb debug a core file (or not)? (Nov. 26, '05, 5:14:35 AM)
Yep. I was linking a cc built library (it used varargs). I am going to port it to stdarg rightaway and use gcc. Thanks.

steveh -> RE: Can gdb debug a core file (or not)? (Mar. 2, '06, 12:02:17 PM)

Got the same here debugging an apache crash:


GNU gdb 2002-11-11-cvs
Copyright 2002 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 "i586-pc-interix3"...
/dev/fs/C/gnu2.intel/egcs.source/gdb/coffread.c:830: internal-error: sect_index_text not initialized
A problem internal to GDB has been detected.  Further
debugging may prove unreliable.
Quit this debugging session? (y or n) y
Create a core file of GDB? (y or n) y
Abort (core dumped)

Even feeding the core from gdb back into gdb gives the same results

Rodney -> RE: Can gdb debug a core file (or not)? (Mar. 2, '06, 10:56:23 PM)
Try setting the final link so that a static binary is created instead of the shared (the default). So add "-static" to the link line. Just a suggestion/workaround.

steveh -> RE: Can gdb debug a core file (or not)? (Mar. 3, '06, 6:43:29 AM)
Unfortunately that causes the following error: cannot find -ldl True enough there is only a .so: locate libld /opt/gcc.3.3/lib/libdl.so /opt/gcc.3.3/lib/libdl.so.3.5 /usr/lib/libdl.so /usr/lib/libdl.so.1 /usr/lib/libdl.so.3.5

Rodney -> RE: Can gdb debug a core file (or not)? (Mar. 3, '06, 2:29:44 PM)
Just remove the "-ldl". It's only needed if you are doing a dynamic load of a shared library. Give the "-static" another whirl without "-ldl" and then, if it still cores, try gdb.

steveh -> RE: Can gdb debug a core file (or not)? (Mar. 3, '06, 2:49:54 PM)

Unfortunately its configure thats erroring but I'll have a dig see what I can come up with:


 + using -ldb for DBM support
      enabling DBM support for mod_rewrite
    o db_auth_module uses ConfigStart/End
      using Berkeley-DB/1.x for mod_auth_db (-ldb)

** A test compilation with your Makefile configuration
** failed.  The below error output from the compilation
** test will give you an idea what is failing. Note that
** Apache requires an ANSI C Compiler, such as gcc.

======== Error Output for sanity check ========
cd ..; gcc  -D_ALL_SOURCE -DNEED_INITGROUPS -I/usr/local/include/ -DMOD_PERL -DUSE_PERL_SSI -D_REENTRANT -D_ALL_SOURCE -DDEBUGGING -
fno-strict-aliasing -I/usr/local/include -D_REENTRANT -D_ALL_SOURCE -DDEBUGGING -fno-strict-aliasing -I/usr/local/include `./apaci`
-I. -I/usr/local/lib/perl5/5.8.3/x86-interix-thread-multi/CORE   -L/usr/local/lib -L/usr/lib -static -o helpers/dummy helpers/dummy.
c   -L/usr/local/lib  -lcrypt -lm -ldb -ldb  -Wl,-E -L/usr/local/lib /usr/local/lib/perl5/5.8.3/x86-interix-thread-multi/auto/DynaLo
ader/DynaLoader.a -L/usr/local/lib/perl5/5.8.3/x86-interix-thread-multi/CORE -lperl -lsocket -ldl -lm -lcrypt -lc
/opt/gcc.3.3/lib/gcc-lib/i586-pc-interix3/3.3/../../../../i586-pc-interix3/bin/ld: cannot find -ldl
collect2: ld returned 1 exit status
make: *** [dummy] Error 1
============= End of Error Report =============

steveh -> RE: Can gdb debug a core file (or not)? (Mar. 3, '06, 7:27:17 PM)

I believe the dependency is coming from perl as perl -V produces:
libs=-lsocket -lgdbm -ldb -ldl -lm -lcrypt -lc

Faking it by creating a copy of libc.a to pass the configure checks then just results in a compile failure:


./os/unix/libos.a(os.o)(.text+0x1c):os.c: undefined reference to `_dlopen'
./os/unix/libos.a(os.o)(.text+0x32):os.c: undefined reference to `_dlclose'
./os/unix/libos.a(os.o)(.text+0x4b):os.c: undefined reference to `_dlsym'
./os/unix/libos.a(os.o)(.text+0x5b):os.c: undefined reference to `_dlerror'
/usr/local/lib/perl5/5.8.3/x86-interix-thread-multi/auto/DynaLoader/DynaLoader.a(DynaLoader.o.b)(.text+0x57b): In function `dl_priva
te_init':
/usr/local/src/perl-5.8.3/ext/DynaLoader/DynaLoader.xs:150: undefined reference to `_dlopen'
/usr/local/lib/perl5/5.8.3/x86-interix-thread-multi/auto/DynaLoader/DynaLoader.a(DynaLoader.o.b)(.text+0x638):/usr/local/src/perl-5.
8.3/ext/DynaLoader/DynaLoader.xs:150: undefined reference to `_dlerror'
/usr/local/lib/perl5/5.8.3/x86-interix-thread-multi/auto/DynaLoader/DynaLoader.a(DynaLoader.o.b)(.text+0x837):/usr/local/src/perl-5.
8.3/ext/DynaLoader/DynaLoader.xs:150: undefined reference to `_dlclose'
/usr/local/lib/perl5/5.8.3/x86-interix-thread-multi/auto/DynaLoader/DynaLoader.a(DynaLoader.o.b)(.text+0x858):/usr/local/src/perl-5.
8.3/ext/DynaLoader/DynaLoader.xs:150: undefined reference to `_dlerror'
/usr/local/lib/perl5/5.8.3/x86-interix-thread-multi/auto/DynaLoader/DynaLoader.a(DynaLoader.o.b)(.text+0xb22):/usr/local/src/perl-5.
8.3/ext/DynaLoader/DynaLoader.xs:150: undefined reference to `_dlsym'
/usr/local/lib/perl5/5.8.3/x86-interix-thread-multi/auto/DynaLoader/DynaLoader.a(DynaLoader.o.b)(.text+0xbdf):/usr/local/src/perl-5.
8.3/ext/DynaLoader/DynaLoader.xs:150: undefined reference to `_dlerror'
collect2: ld returned 1 exit status
make[3]: *** [target_static] Error 1
make[3]: Leaving directory `/var/tmp/apache_1.3.34/src'
make[2]: *** [build-std] Error 2
make[2]: Leaving directory `/var/tmp/apache_1.3.34'
make[1]: *** [build] Error 2
make[1]: Leaving directory `/var/tmp/apache_1.3.34'
make: *** [apaci_httpd] Error 2

Rodney -> RE: Can gdb debug a core file (or not)? (Mar. 3, '06, 11:27:49 PM)
In steveh's case there are actual dynamic load calls for shared libraries. Perhaps whatever is happening to cause the core dump is getting information into the core dump that gdb just gets confused about. For jon493 the static thing may still be helpful. For steveh: you'll have to narrow it down the cause another way. See if syslog or the apache logs have any information to narrow down where the problem happens. You may need to add more debug messages to the source that go to syslog to close in on it.

Page: [1]

0.047