Signal handler in RTEMS

Mon Jan 5 18:07:15 UTC 2015

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?

I know that segfaults are bad, but in order to remove having a log of their existence would be very helpful.

Ben

From: Joel Sherrill [mailto:joel.sherrill at oarcorp.com]
Sent: Monday, January 05, 2015 5:31 AM
To: Nick Withers
Cc: Ben Dart; users at rtems.org
Subject: Re: Signal handler in RTEMS

FWIW I wanted to double check that what I said matched the executable
behavior. I ran on sparc/sis and got this back trace in gdb:

BENS BIG NOTE: Initializing Signal Handler
Doing some looping

Breakpoint 1, _Terminate (
    the_source=the_source at entry=RTEMS_FATAL_SOURCE_EXCEPTION,
    is_internal=is_internal at entry=false, the_error=the_error at entry=33693512)
    at ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:36
36    {
(gdb) bt
#0  _Terminate (the_source=the_source at entry=RTEMS_FATAL_SOURCE_EXCEPTION,
    is_internal=is_internal at entry=false, the_error=the_error at entry=33693512)
    at ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:36
#1  0x02007e80 in rtems_fatal (
    source=source at entry=RTEMS_FATAL_SOURCE_EXCEPTION,
    error=error at entry=33693512)
    at ../../../../../../rtems/c/src/../../cpukit/sapi/src/fatal2.c:34
#2  0x02001b6c in bsp_spurious_handler (trap=265, isf=0x2025db0)
    at ../../../../../../../../rtems/c/src/lib/libbsp/sparc/erc32/startup/spurious.c:131

Just as Nick and I thought, you dereferenced a NULL pointer and caused an access violation.
The processor gave a hardware exception and the BSP caught it.  If code is installed which
maps hardware exceptions -> POSIX signals, then you would have gotten the behavior you
expected.

--joel
On 1/2/2015 8:13 PM, Nick Withers wrote:

On Fri, 2015-01-02 at 20:06 -0600, Joel Sherrill wrote:

On January 2, 2015 7:53:42 PM CST, Nick Withers <nick.withers at anu.edu.au><mailto:nick.withers at anu.edu.au> wrote:

Hello Ben,

I'm not an RTEMS internals expert, but thought I'd try to answer this

anyway - hopefully an expert will chime in to confirm / correct me :-)

On Wed, 2014-12-31 at 13:32 -0800, Ben Dart wrote:

void HandleAndPrintSignal()

{

      printf("I am in the segfault signal handler AND I WILL HANDLE

YOUR SIG!!!!\n");

      while(1){ printf("LALALA\n"); }

      exit(1);

}

void *POSIX_Init(void *args)

{

      printf("BENS BIG NOTE: Initializing Signal Handler\n");

      struct sigaction sa;

      sa.sa_handler = HandleAndPrintSignal;

      sigemptyset(&sa.sa_mask);

      sa.sa_flags = SA_SIGINFO;

      if (sigaction (SIGSEGV, &sa, 0)) {

            printf("A ERROR OCCURED WITH THIS!");

            exit(1);

      }

      int *p = NULL;

      while(1)

      {

            printf("Doing some looping\n");

            *(p--) = 5;

            printf("%d", *p);

      }

}

This will cause a seg fault as expected.

No it won't.

It'll cause a CPU exception, which is what you're seeing.

RTEMS uses a single-process model; there's no "segmentation" / memory

protection between processes (since, again, there's no such thing as

multiple processes).

However instead of being caught by the signal handler a kernel

routine under vectors_init.c will print the following stack trace:

Exception handler called for exception 12 (0xC)

         Next PC or Address of fault = 003506BC

         Saved MSR = 00003012

         Context: Task ID 0x0B010001

         R0  = 003506B8 R1  = 06827C58 R2  = 004A54F8 R3  = 00000000

         R4  = 06827BE8 R5  = 00000013 R6  = 06827C84 R7  = 00000001

         R8  = 00000000 R9  = 00000800 R10 = F0002000 R11 = F0002000

         R12 = 25555582 R13 = 0051A7C0 R14 = 55555555 R15 = 55555555

         R16 = 55555555 R17 = 55555555 R18 = 55555555 R19 = 55555555

         R20 = 55555555 R21 = 55555555 R22 = 06827F10 R23 = 00000001

         R24 = 06827D78 R25 = 003CD20C R26 = 06827D94 R27 = 00000000

         R28 = 006FF698 R29 = 00000013 R30 = 00000000 R31 = 1A01000E

         CR  = 45555582

         CTR = 00350EB0

         XER = 00000000

         LR  = 003506B8

         DAR = 00000000

Stack Trace:

  IP: 0x003506BC, LR: 0x003506B8

--^ 0x0038C364--^ 0x00389AF0--^ 0x0036BC5C--^ 0x00350F70--^

0x0038AD78

--^ 0x0036071C--^ 0x0036D330--^ 0x0036D3B0--^ 0x0033E514--^

0x003399D0

--^ 0x0033B4F0--^ 0x0033D80C--^ 0x0019B68C--^ 0x003C6934--^

0x003C6850

Suspending faulting task (0x0B010001)

Is there something special that needs to be done to set up signal

handlers for RTEMS? It seems like from this manual:

http://docs.rtems.org/doc-current/share/rtems/pdf/posix1003_1.pdf

<http://docs.rtems.org/doc-current/share/rtems/pdf/posix1003_1.pdf%20under%20section%203.3.1.1><http://docs.rtems.org/doc-current/share/rtems/pdf/posix1003_1.pdf%20under%20section%203.3.1.1>

under section 3.3.1.1 indicates that signals have been implemented.

Is there something that I am doing wrong?

You'll never get a segfault under RTEMS. That doesn't mean that invalid

accesses to memory are "OK" though.

Does that make sense?

It was hard to wait for someone else to take a shot at this. :)

Nick is right. There are some POSIX signals which are really exceptions at the hardware level. SIGSEGV, SIGBUS, and SIGFPE come to mind. The exact semantics of what is possible when when occurs is defined by POSIX but the magic starts with an architecture and BSP specific handler. Since the general rule is to avoid these faults in embedded systems, the default action is something like you saw but bsp specific.

Some BSPs have support for installing an addition to the exception handler which will propagate the hardware fault into a software signal but AFAIK this is primarily used to get SIGFPE in languages like Ada mapped to language specific exception handlers.

Since this historically was done for Ada conformance, the common magic is in a BSP file with gnat in the name.

As a general rule, POSIX signals are rarely used in embedded systems, those that originate in hardware exceptions are designed out and considered unrecoverable faults, and the software only signals may be used.

This looks like it came from an ARM BSP. I recall the SPARC BSPs having proper support for this. Not sure if anyone ever wrote the code to map hardware exceptions to POSIX signals for ARM.

At this point, the question is whether this was just an experiment or a needed capability with SIGSEGV.

--joel

Thanks Joel.

Even if a signal was emitted for this case, I'd argue SIGBUS would be

more appropriate than SIGSEGV...?

--

Joel Sherrill, Ph.D.             Director of Research & Development

joel.sherrill at OARcorp.com<mailto:joel.sherrill at OARcorp.com>        On-Line Applications Research

Ask me about RTEMS: a free RTOS  Huntsville AL 35805

Support Available                (256) 722-9985
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20150105/5f89aa23/attachment-0002.html>