Skip navigation.
Home
The QNX Community Portal

View topic - Trapping SIGSEGV and core files

Trapping SIGSEGV and core files

Read-only archive of qnx.rtos (Writing resources managers, and general discussion around the QNX Neutrino RTOS) at inn.qnx.com

Trapping SIGSEGV and core files

Postby Davide Ancri » Fri Oct 28, 2005 5:18 pm

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> */
Davide Ancri
 

Re: Trapping SIGSEGV and core files

Postby John Garvey » Fri Oct 28, 2005 10:57 pm

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;
-----------------------------------------------------------------------
John Garvey
 

Re: Trapping SIGSEGV and core files

Postby Davide Ancri » Mon Oct 31, 2005 8:14 am

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> */
Davide Ancri
 

Re: Trapping SIGSEGV and core files

Postby JohnMcClurkin » Mon Oct 31, 2005 1:08 pm

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;
-----------------------------------------------------------------------
JohnMcClurkin
 

Re: Trapping SIGSEGV and core files

Postby Colin Burgess » Mon Oct 31, 2005 3:11 pm

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
Colin Burgess
 

Re: Trapping SIGSEGV and core files

Postby Wojtek Lerch » Mon Oct 31, 2005 4:27 pm

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.
Wojtek Lerch
 

Re: Trapping SIGSEGV and core files

Postby Chris Herborth » Tue Nov 01, 2005 6:33 pm

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
Chris Herborth
 

Re: Trapping SIGSEGV and core files

Postby JohnMcClurkin » Tue Nov 01, 2005 9:00 pm

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.
JohnMcClurkin
 

Re: Trapping SIGSEGV and core files

Postby Davide Ancri » Fri Nov 04, 2005 9:46 am

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
 

Re: Trapping SIGSEGV and core files

Postby Davide Ancri » Fri Nov 04, 2005 10:15 am

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> */
Davide Ancri
 

Re: Trapping SIGSEGV and core files

Postby Wojtek Lerch » Fri Nov 04, 2005 3:29 pm

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?
Wojtek Lerch
 

Re: Trapping SIGSEGV and core files

Postby David Gibbs » Fri Nov 04, 2005 5:24 pm

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
 

Re: Trapping SIGSEGV and core files

Postby David Gibbs » Fri Nov 04, 2005 5:25 pm

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
David Gibbs
 


Return to qnx.rtos

Who is online

Users browsing this forum: No registered users and 0 guests