Signal handler in RTEMS
chrisj at rtems.org
Tue Jan 6 00:20:17 UTC 2015
On 6/01/2015 5:07 am, Ben Dart wrote:
> The concept of this code was to test the signal handler. The end game
> was to catch a segmentation fault and write a log to a file, detailing
> the segfault and providing a primitive stack trace. Is there a better
> way of doing this that is not writing to file from the kernel?
The details of what you can and cannot do are system specific and there
is no general solution. Being able to catch at a thread level a failure
can be useful, for example a probe of a memory address that may fail
(pluggable hardware) however the scope is limited. Catching a general
failure where something in the software has failed is fatal and not
recoverable. It is like a kernel oops in Linux. What works and what does
not work in undefined.
I have used hooking the fault exception with setjmp/longjmp to implement
a probe during initialisation and it was useful however as a general
rule it becomes difficult when interrupts and contexts are being
switched and on SMP it is another level of complexity again.
> I know that segfaults are bad, but in order to remove having a log of
> their existence would be very helpful.
I implement a data safe in a piece of memory I know can survive a reset
and is not cleared on reset or during initialisation. I then hook all
the exit paths from RTEMS including un-handled exceptions and fill a
structure with a suitable checksum. When the application starts I check
the data safe and if it contains valid data I log it to a file or report
it, eg syslog, then clear the error. I only log the first error and then
count repeated errors until cleared.
More information about the users