This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Attaching and inspecting crash with gdb
- From: Devrim Erdem <devrim dot erdem at gmail dot com>
- To: gdb at sources dot redhat dot com
- Date: Mon, 1 Nov 2004 12:03:58 +0100
- Subject: Attaching and inspecting crash with gdb
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=cKhc7n/83cREG7S2FG4qBXAuUdWp8Kr2/IP+4LeVZgnqNx3VMFwnSZGERvvQxfpDvzX/4+XMaoUOg8W2bv3G3etPJ33mXUyzJ0DgHUURGzlPnT2dKgaGAlvzCZFT44Q1G4Rc4D4FeJN0fDRgOOvIaKP1VBvAOV5FTodEPbMuEPM=
- Reply-to: Devrim Erdem <devrim dot erdem at gmail dot com>
Hello,
Classic problem. Customer uses software heavily. Software crashes from
time to time. No core dumps.
Is there a way of attaching and application and ask gdb to write a
core dump ( or any kind of dump of data ) which I could later load in
gdb to debug the problem remotely.
If this is not possible, I will need to implement my current solution.
The current not so elegant way:
=============================
In my crash crash handler, I simply run a small python script which
attaches gdb to the currently crashed application.
So far I can use the command line argument "--command" to specify
commands like printing the current stack trace. But I need more
information about the crash such as the value of data at the point of
crash.
I would like to be able to tell gdb to do:
For each thread
For each frame ( n to 0 )
print values of all data of the current frame
Then the user sends this text to me and then I can try to figure out
the problem.
But at the moment I can not tell gdb to do a "for" loop for threads
and frames. Is this possible or is there another way of getting the
same kind of information.
Thanks in advance,
Devrim.