Generating coredump's from within a signal handler.

mats.lindberg at mats.lindberg at
Thu Jun 23 08:01:35 GMT 2005

Giorgos Keramidas <keramida at> wrote on 2005-06-22 18:16:37:

> On 2005-06-22 16:00, mats.lindberg at wrote:
> > I'm writing a program that when receiving a SIGTERM
> > shall generate a coredump of itself and exit.
> > This coredump shall be analysed later on using gdb.
> > I've tried to raise(SIGABRT) when handling SIGTERM,
> > this generates a coredump, but the stack seems messed
> > up when examining it with gdb.

> The stack *is* ``messed up'' when a program runs within a signal handler
> (where ``messed up'' means signal handlers are not called as normal C
> functions, but are entered on exit from a system call using special
> stack magic).

> What do you see in the gdb backtrace that seems ``messed up''?

This is it

#0  0x281a337b in kill () from /lib/
#1  0x28198422 in raise () from /lib/
#2  0x080d912a in externalSignals (signo=15) at monitor.c:122
#3  0x080d91c9 in monitorSignalHandler (signo=15) at monitor.c:167
#4  0xbfbfff94 in ?? ()
#5  0x0000000f in ?? ()
#6  0x00000000 in ?? ()
#7  0xbfbfea50 in ?? ()
#8  0x00000002 in ?? ()
#9  0x080d91ae in internalError (signo=136130464) at monitor.c:156
#10 0x080cb12b in doCycleControl () at mngrA.c:707
#11 0x080ca9d4 in mngrA () at mngrA.c:313
#12 0x080bc4c3 in main () at proc0A.c:147

at line 707 there is a call to a regular c-func 'p_time_wait()'
this is not visible in the traceback

monitorSignalHandler(int signo) is setup to handle

signal(SIGSEGV, monitorSignalHandler);
signal(SIGBUS, monitorSignalHandler);
signal(SIGTERM, monitorSignalHandler);
signal(SIGQUIT, monitorSignalHandler);
signal(SIGHUP, monitorSignalHandler);

in monitorSignalHandler() internalError(int signo) is a fallback handler
for unknown signals.
in monitorSignalHandler() a SIGTERM issues a raise(SIGABRT);

So the traceback is messed up as I can understand it;
The process is given a SIGTERM when, probably, in function p_time_wait().
p_time_wait is not visible in the traceback. Instead internalError is shown
with a very strange
signo. The traceback from #3 and up(or down) to zero makes sense. But the
most interesting thing -
the whereabouts of the process when it received SIGTERM is hidden to me.


This e-mail communication (and any attachment/s) may contain confidential
or privileged information and is intended only for the individual(s) or
entity named above and to others who have been specifically authorized to
receive it. If you are not the intended recipient, please do not read,
copy, use or disclose the contents of this communication to others. Please
notify the sender that you have received this e-mail in error by reply
e-mail, and delete the e-mail subsequently.
Thank you.

Ce message (ainsi que le(s) fichier/s), transmis par courriel, peut
contenir des renseignements confidentiels ou protégés et est destiné à
l’usage exclusif du destinataire ci-dessus. Toute autre personne est par
les présentes avisée qu’il est strictement interdit de le diffuser, le
distribuer ou le reproduire. Si vous l’avez reçu par inadvertance, veuillez
nous en aviser et détruire ce message.

More information about the freebsd-questions mailing list