_Internal_error_Occurred() in _Thread_Handler()

[Matthew J Fletcher]

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.


----------- snip ------------

rtems_task test_wake_after(rtems_task_argument ignored)
{
    rtems_task_wake_after(10);
}

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> 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> 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> 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
>> 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.
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-users
>>
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-users
>>
>
>
>
> --
>
> regards
> ---
> Matthew J Fletcher
>
>


-- 

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