From: Jon Ringle <jon.ringle@comdial.com>
To: gdb@sources.redhat.com
Subject: Writing regs to corefile
Date: Mon, 25 Apr 2005 20:42:00 -0000 [thread overview]
Message-ID: <200504251636.13657.jon.ringle@comdial.com> (raw)
Hello,
I have a core file that was generated due to a buggy signal handler. What
happened as far as I can tell, is that my signal handler got called due to a
SIGPIPE signal, however, my signal handler itself also caused a SIGPIPE
signal. I therefore have a recursive signal handler :( Eventually, the process
got a SIGSEGV causing a core dump to be generated. I get the following bt on
the core file:
(gdb) bt
#0 0x401672d8 in _IO_vfprintf (s=0x1d, format=0x20c3afc "\n*** PID %d returning from signal %d @ pc %08x lr %08x\n", ap=Cannot access memory at address 0xbee01f44
) at vfprintf.c:209
#1 0x40175d5c in _IO_vsprintf (string=0x20f7aa8 "\n*** PID 79 returning from signal 13 @ pc 401b9304 lr 401039d8\n",
format=0x20c3afc "\n*** PID %d returning from signal %d @ pc %08x lr %08x\n", args=0xbee0252c) at iovsprintf.c:47
#2 0x020ba51c in dbgPrintf (fmt=0x20c3afc "\n*** PID %d returning from signal %d @ pc %08x lr %08x\n") at dbgprint.c:184
#3 0x0200b278 in client_sigaction (sig=13, psi=0xbee02624, arg=0xbee026a4) at signals.c:103
#4 0x40101fc8 in pthread_sighandler_rt (signo=13, si=0xbee02624, uc=0xbee026a4) at signals.c:119
#5 <signal handler called>
Previous frame inner to this frame (corrupt stack?)
(gdb) frame 3
#3 0x0200b278 in client_sigaction (sig=13, psi=0xbee02624, arg=0xbee026a4) at signals.c:103
103 dbgPrintf("\n*** PID %d returning from signal %d @ pc %08x lr %08x\n", getpid(), sig, (unsigned int)sc->arm_pc, (unsigned int)sc->arm_lr);
(gdb) p/x *sc
$1 = {trap_no = 0x0, error_code = 0x0, oldmask = 0x80000000, arm_r0 = 0xffffffe0, arm_r1 = 0x20f7aa8, arm_r2 = 0x3f, arm_r3 = 0x0, arm_r4 = 0x3f, arm_r5 = 0x20f7aa8, arm_r6 = 0x1f,
arm_r7 = 0xbee02848, arm_r8 = 0xbee028c8, arm_r9 = 0x1d, arm_r10 = 0x40113ac4, arm_fp = 0xbee02730, arm_ip = 0x40113adc, arm_sp = 0xbee02714, arm_lr = 0x401039d8, arm_pc = 0x401b9304,
arm_cpsr = 0x60000010}
I'd like to be able to get to a backtrace of the original SIGPIPE signal. I
then hand edited the core file with the register information from the *sc
above, and got to the previous signal backtrace:
(gdb) bt
#0 0x401b9304 in write () from /home/ringlej/mp1000/trunk-fixes/Soundpipe/install/lib/libc.so.6
#1 0x401039d8 in write (fd=31, buf=0x20f7aa8, n=63) at wrapsyscall.c:139
#2 0x020ba54c in dbgPrintf (fmt=0x20c3afc "\n*** PID %d returning from signal %d @ pc %08x lr %08x\n") at dbgprint.c:188
#3 0x0200b278 in client_sigaction (sig=13, psi=0xbee02848, arg=0xbee028c8) at signals.c:103
#4 0x40101fc8 in pthread_sighandler_rt (signo=13, si=0xbee02848, uc=0xbee028c8) at signals.c:119
#5 <signal handler called>
Previous frame inner to this frame (corrupt stack?)
(gdb) info registers
r0 0xffffffe0 -32
r1 0x20f7aa8 34568872
r2 0x3f 63
r3 0x0 0
r4 0x3f 63
r5 0x20f7aa8 34568872
r6 0x1f 31
r7 0xbee02848 -1092605880
r8 0xbee028c8 -1092605752
r9 0x1d 29
r10 0x40113ac4 1074870980
r11 0xbee02730 -1092606160
r12 0x40113adc 1074871004
sp 0xbee02714 -1092606188
lr 0x401039d8 1074805208
pc 0x401b9304 1075548932
fps 0x0 0
cpsr 0x60000010 1610612752
(gdb) frame 3
#3 0x0200b278 in client_sigaction (sig=13, psi=0xbee02848, arg=0xbee028c8) at signals.c:103
103 dbgPrintf("\n*** PID %d returning from signal %d @ pc %08x lr %08x\n", getpid(), sig, (unsigned int)sc->arm_pc, (unsigned int)sc->arm_lr);
(gdb) p/x *sc
$5 = {trap_no = 0x0, error_code = 0x0, oldmask = 0x80000000, arm_r0 = 0xffffffe0, arm_r1 = 0x20f7aa8, arm_r2 = 0x3f, arm_r3 = 0x0, arm_r4 = 0x3f, arm_r5 = 0x20f7aa8, arm_r6 = 0x1f,
arm_r7 = 0xbee02a6c, arm_r8 = 0xbee02aec, arm_r9 = 0x1d, arm_r10 = 0x40113ac4, arm_fp = 0xbee02954, arm_ip = 0x40113adc, arm_sp = 0xbee02938, arm_lr = 0x401039d8, arm_pc = 0x401b9304,
arm_cpsr = 0x60000010}
I could then hand edit the core file with the *sc register information yet
again to get to the previous signal backtrace. However, this process is
tedious.
Is there another way I could traverse the recursive chain of signal handlers
that is a bit more automatic?
I can't seem to write directly to the core file register set from within gdb
(which is why I was hand editing the core file):
(gdb) set $r0 = 0xffffffe4
You can't do that without a process to debug.
Regards,
Jon
next reply other threads:[~2005-04-25 20:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-25 20:42 Jon Ringle [this message]
2005-04-25 20:51 ` Daniel Jacobowitz
2005-04-25 21:48 ` Jon Ringle
2005-04-26 0:13 ` Daniel Jacobowitz
2005-04-26 0:31 ` Jon Ringle
2005-04-26 1:29 ` Daniel Jacobowitz
2005-04-26 8:16 ` Jon Ringle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200504251636.13657.jon.ringle@comdial.com \
--to=jon.ringle@comdial.com \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox