Determining the cause of a segfault in RTEMS

[Chris Johns]

Mohammed Khoory wrote:
>
> Normally in general-purpose (not embedded) programming, the most
> straightforward way to determine the cause of a segfault is to look at its
> backtrace. However, this approach isn't really helpful in my case.. I'm
> writing an RTEMS application that has around 4 tasks, and stepping through
> the program doesn't exactly show context switches. When I get a segfault,
> the backtrace only shows the following
>
> #0  0xcd95a758 in ?? ()
> #1  0x40000190 in trap_table () at
> ../../../../../../../../rtems-4.10.2/c/src/lib/libbsp/sparc/leon3/../../spar
> c/shared/start.S:88
>
> Which is extremely unhelpful. Stepping through the program also doesn't
> really help, because it seems to crash while waiting for events, which makes
> no sense to me.
>

The stack appears corrupt because the exception stack frame is a 
different format to the standard stack frame gdb expects and attempts to 
decode. All the data is present, it is just not available via gdb's 
stack frame printing.

> Is there any other proper way to figure out what's causing the segfault in
> RTEMS? I'm thinking maybe using the capture engine might be a good idea
> because it should tell what task was running last, but I haven't used it
> yet, I only know what it does.. so I'm not sure if that'll help.

This is architecture and sometimes BSP specific so exact details are not 
easy to give. The best solution is find the address the exception is 
branching to and then set a break point there. The idea is to get as 
close to the point the exception happens. More often than not this lets 
you see a decent stack frame in gdb. Have a look start.S and see if it 
is easy to see a possible entry point.

Which version of RTEMS are you using ?

Which BSP are you using ?

Chris