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)

it there a way to trap SIGSEGV (and friendrs like SIGFPE) to performsomething like a syslog, and then return exactly to the same point wherethe 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, dowhatever you want in the signal handler (syslog, etc) and then restorethe handler to SIG_DFL and let it return; the offending code will beretried, and since you didn't do anything to make it work and no longerhave a handler, it will do the default action and die/make corefile/etc.

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

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 performsomething like a syslog, and then return exactly to the same pointwhere the damage has occurred, to let the O.S. generating a completecore file?

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

Note however that you won't be able to load shared libs automaticallythis 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, dowhatever you want in the signal handler (syslog, etc) and then restorethe handler to SIG_DFL and let it return; the offending code will beretried, and since you didn't do anything to make it work and no longerhave a handler, it will do the default action and die/make corefile/etc.

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

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.

Sure. Install a signal handler for the signals you wish to trap, dowhatever you want in the signal handler (syslog, etc) and then restorethe handler to SIG_DFL and let it return; the offending code will beretried, and since you didn't do anything to make it work and no longerhave 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)...

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

No. PhAppAddSignalProc() is not meant to be used with this kind ofsignals. It installs a "real" signal handler that just sets some flagand returns and allows your application to finish what it was doing, andthen the main loop picks up the flag and calls your callback at somepoint later. This scheme doesn't work in a situation where you can'tsafely return from the "real" signal handler. Just use signal() orsigaction() -- you don't intend to let your application try to finishwhat 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.

I'd just like to point out that syslog() and fprintf() aren't on thelist of functions that are safe to call from a signal handler, foundnear 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 anotherSIGSEGV?

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

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

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 soeasy over the net... stripping data from the core usually makes itbecome much smaller, still leaving the capability to inspect the stacktrace of SIGSEGV scenario.

Another choice -- ask your sales rep/sale engineer for thecode to dumper. It is fairly simple, and could allow youto 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, theycould 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 automaticallythis way (since gdb needs stuff that's in the data segment to dothat)

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 soeasy over the net... stripping data from the core usually makes itbecome much smaller, still leaving the capability to inspect the stacktrace of SIGSEGV scenario.