| All Forums |
Register |
Login |
Search |
Subscriptions |
My Profile |
Inbox |
| Tool Warehouse |
FAQs |
Resources |
Help |
Member List |
Address Book |
Logout |
|
|
Can gdb debug a core file (or not)?
|
Logged in as: Guest |
| Users viewing this topic: none |
|
Login  |
|
|
 Can gdb debug a core file (or not)? - Nov. 15, '05, 3:35:28 AM
|
|
|
jon493
Posts: 56
Joined: Oct. 14, '05,
Status: offline
|
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.
|
|
|
|
|
RE: Can gdb debug a core file (or not)? - Nov. 15, '05, 5:54:38 AM
|
|
|
Rodney
Posts: 3714
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
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.
|
|
|
|
|
RE: Can gdb debug a core file (or not)? - Nov. 26, '05, 5:14:35 AM
|
|
|
jon493
Posts: 56
Joined: Oct. 14, '05,
Status: offline
|
Yep. I was linking a cc built library (it used varargs). I am going to port it to stdarg rightaway and use gcc. Thanks.
|
|
|
|
|
RE: Can gdb debug a core file (or not)? - Mar. 2, '06, 12:02:17 PM
|
|
|
steveh
Posts: 195
Joined: Jan. 23, '04,
Status: offline
|
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
|
|
|
|
|
RE: Can gdb debug a core file (or not)? - Mar. 2, '06, 10:56:23 PM
|
|
|
Rodney
Posts: 3714
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
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.
|
|
|
|
|
RE: Can gdb debug a core file (or not)? - Mar. 3, '06, 6:43:29 AM
|
|
|
steveh
Posts: 195
Joined: Jan. 23, '04,
Status: offline
|
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
|
|
|
|
|
RE: Can gdb debug a core file (or not)? - Mar. 3, '06, 2:29:44 PM
|
|
|
Rodney
Posts: 3714
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
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.
|
|
|
|
|
RE: Can gdb debug a core file (or not)? - Mar. 3, '06, 2:49:54 PM
|
|
|
steveh
Posts: 195
Joined: Jan. 23, '04,
Status: offline
|
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 =============
|
|
|
|
|
RE: Can gdb debug a core file (or not)? - Mar. 3, '06, 7:27:17 PM
|
|
|
steveh
Posts: 195
Joined: Jan. 23, '04,
Status: offline
|
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
|
|
|
|
|
RE: Can gdb debug a core file (or not)? - Mar. 3, '06, 11:27:49 PM
|
|
|
Rodney
Posts: 3714
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
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.
|
|
|
|
 New Messages |
 No New Messages |
 Hot Topic w/ New Messages |
 Hot Topic w/o New Messages |
|
 Locked w/ New Messages |
 Locked w/o New Messages |
|
 Post New Thread
Reply to Message
Post New Poll
Submit Vote
Delete My Own Post
Delete My Own Thread
Rate Posts |
|
|
|
Printable Version
