gdb and shared memory

[Christopher Neufeld <neufeld@physics.utoronto.ca>]

   Hello,

   I was talking with some folks at Linux Expo last week about a fairly
technical gdb question, and they suggested that I enquire at this email
address.

   I have a program with multiple abort() traps for unusual
circumstances, I can get a core dump, do a backtrace in gdb, and find out
what the state of the program was when it gave up. This worked fine until
fairly recently, when I rewrote the output routines to use shared memory
segments and a dedicated writer (the resulting asynchronous writing saves
me about a factor of two in run time). Unfortunately, the core files are
now in a format which prevents my usual technique from working.
   It appears that "gdb" is confused by the shared memory addresses in
the core dump. When I run gdb, then issue the commands "file myprogram"
"core core", I get the following:

Core was generated by ....
Program terminated with signal 6, IOT trap/Abort.
Cannot access memory at address 0x40007138
#0  0x806fee9 in kill ()
(gdb) bt
#0  0x806fee9 in kill ()
Cannot access memory at address 0xbffff414
(gdb)


   So, I can't get at the program state saved in the core file, and I
have to rerun the program within the debugger (that works fine, I can do
a backtrace after the abort() gets called).
   My question, then, is this: is there a magic command I don't know
about which informs "gdb" that I don't care if it can't get at the shared
memory segments, the state I'm interested is in the process' unshared
core, and I'd like to be able to backtrace and see what happened.

   Thank you for any help you might be able to provide.


-- 
 Christopher Neufeld                   neufeld@physics.utoronto.ca
 Home page:  http://caliban.physics.utoronto.ca/neufeld/Intro.html
 "Don't edit reality for the sake of simplicity"