_Internal_error_Occurred() in _Thread_Handler()

[Matthew J Fletcher]

Thanks for the reply, what exception routines would be called ? i dont
believe there is a data abort, invalid instruction, etc exception being
thrown at any point.

I will try git head at some point, i am using mingw and there are problems
with the 2.69 autoconf which means you cannot even configure.



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

> 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<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/42ea412b/attachment-0001.html>