core while attached

Bennett F. Dill
2003-01-27T18:31:45Z

I hope that someone out there has the patience to look at my problem :-)

Hi, I'm working with gdb and I have the -g option on my application.
Typically I get very descriptive error messages. This latest problem
however is really interesting though... It seems to be a problem with
libc.so.1...

[history]
Anyway, the application runs in the background and is a server to about
25 clients concurrently. It takes a few hours for the app to sigsegv.
Now, it never dumped a core for some reason, so i just attach gdb to the
process and continue and wait for the error to rear its head. Now,
since the app serves ~25 people, I don't really have time to look around
with the debugger... (I'm new to gdb, noo suprise I'm sure)
[/history]

So my question is, is it possible to have the gdb that is attached to a
running process that has hit a signal sigsegv, to dump a core? This
way I can leisurly mull over the data.

More questions I have (totally n00bishness I'm sure), is how can I
find out what line of code in my app, called the 'deadly' function in
libc.so.1 (fprintf) and is there any way to view the call to fprintf
based on the memory address?

Below is what I get from a where or a BT etc... If I try to use a
'return' I go no where real fast.

TIA for your assistance :-)
Ben

Program received signal SIGSEGV, Segmentation fault.
0xff30ceb8 in _getorientation () from /usr/lib/libc.so.1
(gdb) where
#0 0xff30ceb8 in _getorientation () from /usr/lib/libc.so.1
#1 0xff30d0dc in _set_orientation_byte () from /usr/lib/libc.so.1
#2 0xff300710 in fprintf () from /usr/lib/libc.so.1
#3 0x3aa80 in ?? ()
#4 0x30420 in ?? ()
#5 0x2f6f0 in ?? ()
#6 0x2c7c8 in ?? ()
#7 0x2c258 in ?? ()
(gdb)