Signal handler in RTEMS

[Chris Johns]

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.

Chris