<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div>Hi,<br><br></div>So i put breakpoints in the places you mentioned in the _Thread_Handler, this is what occurred.<br><br></div>1) Init() thread scheduled<br>
</div>2) Init() creates 'test_wake_after' thread<br></div>3) Init() deletes itself<br></div>4) test_wake_after is scheduled (this and the idle thread are now the only ones executing)<br></div>5) rtems_task_wake_after() called from within test_wake_after() context<br>
</div>6) rtems_idle() is now scheduled<br></div>7) rtems_idle() is scheduled again<br></div>8) my idle loop is just a for(;;) and the disassembly shows that<br></div>9) i hit the breakpoint showing a function has returned in _Thread_Handler()<br>
</div>10) the execution->start->entry_point is "test_wake_after".<br><br></div>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.<br>
<br></div>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.<br><br></div>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.<br>
</div><div><div><br></div><div>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 !<br>
</div><div><div><br><br></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 3 April 2013 11:00, Sebastian Huber <span dir="ltr"><<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 04/03/2013 11:44 AM, Matthew J Fletcher wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 > then the system is broken.  This can be a general memory corruption (heap,<br>
stack, global > variables) or a bug in the exception processing.<br>
<br>
Do you know where the rtems executive tests for and detects a return from a<br>
thread so i can investigate further ?<br>
</blockquote>
<br></div>
It is all in _Thread_Handler()<br>
<br>
<a href="http://git.rtems.org/rtems/tree/cpukit/score/src/threadhandler.c" target="_blank">http://git.rtems.org/rtems/<u></u>tree/cpukit/score/src/<u></u>threadhandler.c</a><br>
<br>
in line 139 we have the call to the thread entry and in line 178 the internal error.<div class="HOEnZb"><div class="h5"><br>
<br>
-- <br>
Sebastian Huber, embedded brains GmbH<br>
<br>
Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
Phone   : <a href="tel:%2B49%2089%20189%2047%2041-16" value="+4989189474116" target="_blank">+49 89 189 47 41-16</a><br>
Fax     : <a href="tel:%2B49%2089%20189%2047%2041-09" value="+4989189474109" target="_blank">+49 89 189 47 41-09</a><br>
E-Mail  : <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-<u></u>brains.de</a><br>
PGP     : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div><br>regards</div><div>---</div><div>Matthew J Fletcher</div><br>
</div>