_Internal_error_Occurred() in _Thread_Handler()

Sebastian Huber sebastian.huber at embedded-brains.de
Wed Apr 3 13:39:07 UTC 2013

On 04/03/2013 03:22 PM, Matthew J Fletcher wrote:
> So i put breakpoints in the places you mentioned in the _Thread_Handler, this
> is what occurred.
> 1) Init() thread scheduled
> 2) Init() creates 'test_wake_after' thread
> 3) Init() deletes itself
> 4) test_wake_after is scheduled (this and the idle thread are now the only ones
> executing)
> 5) rtems_task_wake_after() called from within test_wake_after() context
> 6) rtems_idle() is now scheduled
> 7) rtems_idle() is scheduled again
> 8) my idle loop is just a for(;;) and the disassembly shows that
> 9) i hit the breakpoint showing a function has returned in _Thread_Handler()
> 10) the execution->start->entry_point is "test_wake_after".
> So two strange things have occurred, the last scheduled thread was rtems_idle()
> but the execution structure is showing that "test_wake_after",.. maybe thats
> ok, it might have been chosen to execute next i suppose.
> Even stranger was that the for(;;) inside rtems_idle() somehow returned,. now i
> put code after the for(;;) and a breakpoint and it was not hit.
> I admit that the program is not following logically how it would appear to, but
> its difficult to put that down to heap or stack corruption as 3 tasks where
> scheduled correctly, and anyhow how would that modify the (in RAM) code to
> modify the instructions so that instead of a branch to itself it did a 'bx rX'
> where r is a register with a sensible return address. Given that i only have 2
> tasks running, both of which are just for(;;) loops, but one calls an rtems
> routines, it seems unlikely that heap/stack corruption would occur.
> I suppose the only way to tell for sure is to dump the address in RAM of the
> function that has 'returned' into _Thread_Handler, and see if somehow it has a
> bx instruction and then try and work out where/what managed to modify that
> function so accurately as to insert valid thumb asm !

There can be also a bug in the exception processing code.  It would really help 
if you can provide a simple self-contained test case.  The ARM code changed 
considerably in RTEMS 4.11 and this is what I use.  I never worked with 4.10.

Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

More information about the users mailing list