does rtems 5.1 support create a core dump file when accessing a invalid address or other fatal errors?

Chris Johns chrisj at
Wed Sep 16 02:17:50 UTC 2020

On 16/9/20 11:45 am, smallphd at wrote:
> Thanks very much for you reply.  I get many useful information from your suggestion.

No problem.

> Our BSP has a 8MB memory for rtems and a 32MB flash device. So it may not spend
> too much time for dumping the core. 
> The question is that our application running with rtems is very complex. There
> are several threads and many async processes.
> When the fatal error happened, it is possible that the backtrace of current
> thread is not enough.
> We need analyse other data structures to debug, such as all items in a queue or
> some global variable.

That is fine. Complex applications are what we want to hear about. :)

> What's more, when our product sold to consumer and some bugs trigger a crash. We
> could not connect to user's environment to debug.
> So, it will be a better option if a core dump is generated.

You need to capture something but do you need all the memory.

> However, if the core dump policy is not possible, the method you provided is
> feasible.

A core dump might be possible, it is just not currently available. A workable
core would be hard and I suspect would have a number of limitations and it would
take a lot of core developer time to do. Apart of the target capture side we
would need to teach GDB to understand the core image and RTEMS threads so you
could switch threads and provide a backtrace. That alone is a sizeable piece of

> I will study it and check how it will be integrated to our system.

I would select the important data you need to know and then add it to the RTE
struct. What you capture is not limited to what RTEMS provides. You are free to
instrument your application and capture that data on a crash.


More information about the devel mailing list