Determining the cause of a segfault in RTEMS

[Angelo Fraietta]

Just one thing with possibly considering.

I had this problem a while ago and it was caused by my stack size being 
too small. One task was writing into another task spot.

If you can reproduce the problem, give it a go and see if it helps

On 13/03/2013 11:51 AM, Mohammed Khoory wrote:
> Hi,
>
> 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.
>
> 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.
>
> Thanks
>
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>