On 05/04/2010 02:40 PM, Jamey Sharp wrote:
Of course if this application is forking, it can be quite tricky to get gdb attached to the process that actually dies. It may be easier to run `ulimit -c unlimited` to enable core dumps, then let the application die, then use `gdb -c` to inspect the coredump.
I've been doing some more fiddling with this, and I managed to get a viable stack trace using winedbg; see attached. (It should be a lot smaller than the last attachment. Is there any easy way to prevent attachments from being displayed inline that way when they're so big?) I also included a register dump, just in case that would be useful. Looking at the dump now, though, I'm suddenly no longer sure that it was taken at the correct stack frame; take it with a grain of salt. I can re-run the debug session if necessary.
When you have the failed process in GDB, it would also help to go to the _XReply stack frame and print dpy->request and dpy->last_request_read. I'm guessing those will be 9 and 8, respectively.
Unfortunately, I was not able to manage this. Possibly I don't understand how to "go to the_XReply stack frame"; I tried both 'select-frame 3' and 'frame 3' (the latter of which did print '#3 0x7e7a7f44 in _XReply () from /usr/lib32/libX11.so.6'), but both ways, I got only 'No symbol "dpy" in current context." -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
