_Internal_error_Occurred() in _Thread_Handler()

[Matthew J Fletcher]

Hi,

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 !




On 3 April 2013 11:00, Sebastian Huber
<sebastian.huber at embedded-brains.de>wrote:

> On 04/03/2013 11:44 AM, Matthew J Fletcher wrote:
>
>>  > then the system is broken.  This can be a general memory corruption
>> (heap,
>> stack, global > variables) or a bug in the exception processing.
>>
>> Do you know where the rtems executive tests for and detects a return from
>> a
>> thread so i can investigate further ?
>>
>
> It is all in _Thread_Handler()
>
> http://git.rtems.org/rtems/**tree/cpukit/score/src/**threadhandler.c<http://git.rtems.org/rtems/tree/cpukit/score/src/threadhandler.c>
>
> in line 139 we have the call to the thread entry and in line 178 the
> internal error.
>
>
> --
> 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<sebastian.huber at embedded-brains.de>
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>



-- 

regards
---
Matthew J Fletcher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20130403/42baddf0/attachment-0001.html>