Trapping SIGSEGV and core files

[Davide Ancri]

Hi all

it there a way to trap SIGSEGV (and friendrs like SIGFPE) to perform
something like a syslog, and then return exactly to the same point where
the damage has occurred, to let the O.S. generating a complete core file?

Another core-related question: is there an utility to strip data segment
from a complete core? (Like if it was generated with only code and stack
trace)

Thanks in advance
Davide


--
/* Ancri Davide - <davidea at prisma-eng dot it> */

[John Garvey]

Davide Ancri wrote:

it there a way to trap SIGSEGV (and friendrs like SIGFPE) to perform
something like a syslog, and then return exactly to the same point where
the damage has occurred, to let the O.S. generating a complete core file?

Sure. Install a signal handler for the signals you wish to trap, do
whatever you want in the signal handler (syslog, etc) and then restore
the handler to SIG_DFL and let it return; the offending code will be
retried, and since you didn't do anything to make it work and no longer
have a handler, it will do the default action and die/make corefile/etc.

Here's a complete example:

-----------------------------------------------------------------------
$ cat segv.c
#include <signal.h>
#include <stdio.h>

void handler(int signo)
{
fprintf(stderr, "about to die from signal %d\n", signo);
signal(signo, SIG_DFL);
}

int main(int argc, char *argv[])
{
int *ptr, value;

signal(SIGSEGV, handler);

ptr = NULL;
value = *ptr;

return(0);
}
-----------------------------------------------------------------------
$ ./segv
about to die from signal 11
Memory fault (core dumped)
-----------------------------------------------------------------------
$ gdb ./segv --core=/var/dumps/segv.core
#0 0x08048532 in main (argc=1, argv=0x8047960) at segv.c:17
17 value = *ptr;
-----------------------------------------------------------------------

[Davide Ancri]

John Garvey wrote:

Sure. Install a signal handler for the signals you wish to trap, do
whatever you want in the signal handler (syslog, etc) and then restore
the handler to SIG_DFL and let it return; the offending code will be
retried, and since you didn't do anything to make it work and no longer
have a handler, it will do the default action and die/make corefile/etc.

Here's a complete example:

Thanks a lot!

And what about "stripping data" from large core files? Any hint?

Davide

--
/* Ancri Davide - <davidea at prisma-eng dot it> */

[JohnMcClurkin]

In a Photon application, can you achieve the same result by putting a
call to PtAppRemoveSignal() in a signal handler that was installed by
PhAppAddSignalProc?

John Garvey wrote:

Davide Ancri wrote:

it there a way to trap SIGSEGV (and friendrs like SIGFPE) to perform
something like a syslog, and then return exactly to the same point
where the damage has occurred, to let the O.S. generating a complete
core file?


Sure. Install a signal handler for the signals you wish to trap, do
whatever you want in the signal handler (syslog, etc) and then restore
the handler to SIG_DFL and let it return; the offending code will be
retried, and since you didn't do anything to make it work and no longer
have a handler, it will do the default action and die/make corefile/etc.

Here's a complete example:

-----------------------------------------------------------------------
$ cat segv.c
#include <signal.h
#include <stdio.h

void handler(int signo)
{
fprintf(stderr, "about to die from signal %d\n", signo);
signal(signo, SIG_DFL);
}

int main(int argc, char *argv[])
{
int *ptr, value;

signal(SIGSEGV, handler);

ptr = NULL;
value = *ptr;

return(0);
}
-----------------------------------------------------------------------
$ ./segv
about to die from signal 11
Memory fault (core dumped)
-----------------------------------------------------------------------
$ gdb ./segv --core=/var/dumps/segv.core
#0 0x08048532 in main (argc=1, argv=0x8047960) at segv.c:17
17 value = *ptr;
-----------------------------------------------------------------------

[Colin Burgess]

dumper -m will only dump the stack.

You can tell gdb to use the symbol file for code segments
with

set trusted-readonly-sections 1

Note however that you won't be able to load shared libs automatically
this way (since gdb needs stuff that's in the data segment to do that)

Davide Ancri wrote:

John Garvey wrote:


Sure. Install a signal handler for the signals you wish to trap, do
whatever you want in the signal handler (syslog, etc) and then restore
the handler to SIG_DFL and let it return; the offending code will be
retried, and since you didn't do anything to make it work and no longer
have a handler, it will do the default action and die/make corefile/etc.

Here's a complete example:


Thanks a lot!

And what about "stripping data" from large core files? Any hint?

Davide

--
cburgess@qnx.com

[Wojtek Lerch]

JohnMcClurkin wrote:

In a Photon application, can you achieve the same result by putting a
call to PtAppRemoveSignal() in a signal handler that was installed by
PhAppAddSignalProc?

No. PhAppAddSignalProc() is not meant to be used with this kind of
signals. It installs a "real" signal handler that just sets some flag
and returns and allows your application to finish what it was doing, and
then the main loop picks up the flag and calls your callback at some
point later. This scheme doesn't work in a situation where you can't
safely return from the "real" signal handler. Just use signal() or
sigaction() -- you don't intend to let your application try to finish
what it was doing when the signal hit it anyway.

[Chris Herborth]

John Garvey wrote:

Sure. Install a signal handler for the signals you wish to trap, do
whatever you want in the signal handler (syslog, etc) and then restore
the handler to SIG_DFL and let it return; the offending code will be
retried, and since you didn't do anything to make it work and no longer
have a handler, it will do the default action and die/make corefile/etc.
[...]
void handler(int signo)
{
fprintf(stderr, "about to die from signal %d\n", signo);
signal(signo, SIG_DFL);
}

I'd just like to point out that syslog() and fprintf() aren't on the
list of functions that are safe to call from a signal handler, found
near the beginning of the handy-dandy Library Reference book.

Also note that there are certain signals that can't be caught (SIGKILL
for example)...

--
Chris Herborth (cherborth@qnx.com) - Senior Zombiologist and Tech Writer
Never send a monster to do the work of an evil scientist.
Monthly QNX newsletter - http://www.qnx.com/news/forms/newsletter.html

[JohnMcClurkin]

Wojtek Lerch wrote:

JohnMcClurkin wrote:

In a Photon application, can you achieve the same result by putting a
call to PtAppRemoveSignal() in a signal handler that was installed by
PhAppAddSignalProc?


No. PhAppAddSignalProc() is not meant to be used with this kind of
signals. It installs a "real" signal handler that just sets some flag
and returns and allows your application to finish what it was doing, and
then the main loop picks up the flag and calls your callback at some
point later. This scheme doesn't work in a situation where you can't
safely return from the "real" signal handler. Just use signal() or
sigaction() -- you don't intend to let your application try to finish
what it was doing when the signal hit it anyway.
Thanks,

Using sigaction in this way allows my app to shut down it's A/D adapter
in an orderly way and produces a core file.

[Davide Ancri]

Chris Herborth wrote:

I'd just like to point out that syslog() and fprintf() aren't on the
list of functions that are safe to call from a signal handler, found
near the beginning of the handy-dandy Library Reference book.

I think the danger of syslog()ging something while handling a SIGSEGV is
acceptable: what does "Signal handler unsafe" means? Risk of another
SIGSEGV?

The "thread unsafeness" declared for the syslog() call sounds a lot more
strange to my ears! Most multithreaeded process need to syslog events in
many of their threads... should it be done under mutex protection?

Davide

--
/* Ancri Davide - <davidea at prisma-eng dot it> */

[Davide Ancri]

Colin Burgess wrote:

dumper -m will only dump the stack.

You can tell gdb to use the symbol file for code segments with

set trusted-readonly-sections 1

Note however that you won't be able to load shared libs automatically
this way (since gdb needs stuff that's in the data segment to do
that)

The problem is different: let's say an application uses 100MB of data,
an it crashes on a system on the other side of the globe

Sending a 100 MB core (or 50 MB if succesfully gzipped) is not always so
easy over the net... stripping data from the core usually makes it
become much smaller, still leaving the capability to inspect the stack
trace of SIGSEGV scenario.

Thanks anyway!
Davide

--
/* Ancri Davide - <davidea at prisma-eng dot it> */

[Wojtek Lerch]

Davide Ancri wrote:

I think the danger of syslog()ging something while handling a SIGSEGV is
acceptable: what does "Signal handler unsafe" means? Risk of another
SIGSEGV?

Risk of going into an infinite loop that continuously sends complete
garbage to syslog?

[David Gibbs]

Davide Ancri <falsemail@nospam.xx> wrote:

Another choice -- ask your sales rep/sale engineer for the
code to dumper. It is fairly simple, and could allow you
to completely customize what you put in the dump file.

Another possible choice: take a look at setrlimit(), in
particular the RLIMIT_CORE limit to limit the size of a
corefile. (Though, that appears to be per-process, so
may not work globally... but for your 100M processes, they
could set it.)

-David

Colin Burgess wrote:
dumper -m will only dump the stack.

You can tell gdb to use the symbol file for code segments with

set trusted-readonly-sections 1

Note however that you won't be able to load shared libs automatically
this way (since gdb needs stuff that's in the data segment to do
that)

The problem is different: let's say an application uses 100MB of data,
an it crashes on a system on the other side of the globe

Sending a 100 MB core (or 50 MB if succesfully gzipped) is not always so
easy over the net... stripping data from the core usually makes it
become much smaller, still leaving the capability to inspect the stack
trace of SIGSEGV scenario.

Thanks anyway!
Davide

--
/* Ancri Davide - <davidea at prisma-eng dot it> */

--
David Gibbs
QNX Training Services
dagibbs@qnx.com

[David Gibbs]

Davide Ancri <falsemail@nospam.xx> wrote:

Or, "dumper -s size" will limit the maximum size of the corefile.

-David
--
David Gibbs
QNX Training Services
dagibbs@qnx.com