_Internal_error_Occurred() in _Thread_Handler()

[Joel Sherrill]

On 4/2/2013 9:45 AM, Matthew J Fletcher wrote:
> Hi
>
> After some debugging i've found that in some cases a task that calls 
> rtems_task_wake_after() will cause the _Thread_Handler to think its 
> returned. Has anyone observed this before ?
>
> A simple case as shown bellow does NOT fail, but a more complex 
> example with 30+ tasks, 40+ timers etc does seem to reproducibly fail.
I hope it reliably does this since this failure is by design. :)
>
>
> ----------- snip ------------
>
> rtems_task test_wake_after(rtems_task_argument ignored)
> {
>     rtems_task_wake_after(10);
Add "rtems_task_delete( RTEMS_SELF);"
> }
>
At this point, "test_wake_after()" returns and that is considered
a fatal error in the Classic API.

With a quick look through the manual, I don't see a reference to this
though. Any suggestions on where you would have looked to find this
information?

Or where it should be -- even if it has to be repeated.
> rtems_task Init( rtems_task_argument ignored )
> {
>     rtems_status_code status;
>     rtems_id id;
>
>     status = rtems_task_create( "wake_after",
>         23,
>           1024,
>         RTEMS_DEFAULT_MODES,
>         RTEMS_FLOATING_POINT | RTEMS_DEFAULT_ATTRIBUTES,
>         &id
>     );
>
>     status = rtems_task_start(id, test_wake_after, NULL);
>
>     for (;;)
>     {
>     }
> }
>
>
> On 28 March 2013 15:28, Matthew J Fletcher <amimjf at gmail.com 
> <mailto:amimjf at gmail.com>> wrote:
>
>     Thanks all for the suggestions.
>
>     Looking at the 'executing' structure in _Thread_Handler() i can
>     see that the last task being executed was the
>     rtems_bdbuf_swapout_task(), i dont see how this can return, the
>     only chance out of this seems to be via
>     rtems_fatal_error_occured() which in the rtl22xx_t BSP is
>     implemented as..
>
>     void rtems_fatal_error_occurred(
>       uint32_t   the_error
>     ) RTEMS_COMPILER_NO_RETURN_ATTRIBUTE; Thats just defined as
>     __attribute__ ((noreturn));
>
>     The return argument is 0x814c9c50, return code 6 according to the
>     'executing' structure.
>
>     If i comment out the rtems_io_register_driver() /
>     rtems_rfs_format() on the NV device the problem does not occur, i
>     just switch between the idle task and one of my threads.
>
>     So it looks like rtems_bdbuf_swapout_task() is returning, can i
>     help any more tracking things down ?
>
>
>
>
>
>     On 28 March 2013 14:03, Joel Sherrill <Joel.Sherrill at oarcorp.com
>     <mailto:Joel.Sherrill at oarcorp.com>> wrote:
>
>         Just to directly answer the question about the idle thread. It
>         is perfectly normal to have a system where that is the only
>         ready thread. Even ticker spends most of its execution time in
>         this state.
>
>         POSIX threads implicitly delete themselves when they return.
>
>         It is a fatal error for Classic API tasks to do so.
>
>         This is just one example of the differing philosophies behind
>         the two APIs.
>
>         --joel
>
>         Sebastian Huber <sebastian.huber at embedded-brains.de
>         <mailto:sebastian.huber at embedded-brains.de>> wrote:
>
>
>         On 03/28/2013 01:26 PM, Matthew J Fletcher wrote:
>         > Hi,
>         >
>         > I am getting the above and presume i've made a mistake in
>         some part of my setup.
>         >
>         > I know task switching works, i switch between the idle task
>         and my Init() task
>         > fine, this error seems to occur in the task switch that
>         occurs after i
>         > rtems_task_suspend() the Init() task. That in itself i guess
>         is fine, most of
>         > the examples do it.
>         >
>         > Would the above happen if there were no ready to be
>         scheduled tasks except the
>         > idle task ?
>
>         The only internal error in _Thread_Handler() is
>         INTERNAL_ERROR_THREAD_EXITTED.
>           The classic API tasks must not return.  You have to delete
>         them, e.g. with
>         rtems_task_delete(RTEMS_SELF);
>
>         --
>         Sebastian Huber, embedded brains GmbH
>
>         Address : Dornierstr. 4, D-82178 Puchheim, Germany
>         Phone   : +49 89 189 47 41-16 <tel:%2B49%2089%20189%2047%2041-16>
>         Fax     : +49 89 189 47 41-09 <tel:%2B49%2089%20189%2047%2041-09>
>         E-Mail  : sebastian.huber at embedded-brains.de
>         <mailto:sebastian.huber at embedded-brains.de>
>         PGP     : Public key available on request.
>
>         Diese Nachricht ist keine geschäftliche Mitteilung im Sinne
>         des EHUG.
>         _______________________________________________
>         rtems-users mailing list
>         rtems-users at rtems.org <mailto:rtems-users at rtems.org>
>         http://www.rtems.org/mailman/listinfo/rtems-users
>
>         _______________________________________________
>         rtems-users mailing list
>         rtems-users at rtems.org <mailto:rtems-users at rtems.org>
>         http://www.rtems.org/mailman/listinfo/rtems-users
>
>
>
>
>     -- 
>
>     regards
>     ---
>     Matthew J Fletcher
>
>
>
>
> -- 
>
> regards
> ---
> Matthew J Fletcher
>


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20130402/f88e1f16/attachment-0001.html>