Issue with Task delete

[ali nasir]

Hi,
 
I am not sure, what does it wait for as i cannot see the task in the OS. There is a call to fwalk (which is called from _reclaim_reent) from the newlib_delete_hook which never returns. There is no crash of the system. 
I also noticed that further dynamic memory allocations are blocked for the tasks which are already launched. 
 
I see if there is an fprintf call from this task, only then we see the problem. If there is no fprintf, then everything works fine. This could be the clue to find the problem. 
 
Below is the code which you can look at. I have not shown launch of other tasks which are launched in the context of the InitMainTask. These are basically network daemons, ramdisk, flashdisk initializations. But as i said, if we remove the fprintf, then the newlib_delete_hook will return back. The delete of the Init however works fine.
 
Init(rtems_task_argument ignored)
{
    rtems_mode old_mode;
    rtems_task_mode( RTEMS_INTERRUPT_LEVEL(6),RTEMS_INTERRUPT_MASK, &old_mode);
    /* This function does the initialization of the hardware and launching of the application's main thread */
    init_main();
    rtems_task_mode( RTEMS_INTERRUPT_LEVEL(0),RTEMS_INTERRUPT_MASK, &old_mode);
    rtems_task_delete( RTEMS_SELF );
}
init_main()
{
 const char namestring[] = "Tsk1";
 rtems_status_code    status;
        rtems_name name = rtems_build_name(
          namestring[0],
          namestring[1],
          namestring[2],
          namestring[3]);
 rtems_id            rtos_task_id;
        status = rtems_task_create( name, 1,
            4096,
            RTEMS_PREEMPT | RTEMS_NO_TIMESLICE | RTEMS_NO_ASR |RTEMS_INTERRUPT_LEVEL(0),
            RTEMS_FLOATING_POINT | RTEMS_LOCAL,
            &rtos_task_id);
 rtems_task_mode(RTEMS_PREEMPT, RTEMS_PREEMPT_MASK, &previous_mode);
 status = rtems_task_start(rtos_task_id, (rtems_task_entry)InitMainTask, 0);
}
InitMainTask()
{
        freopen ("/dev/ttyS0","r",stdin);
        freopen ("/dev/ttyS0","w",stdout);
        freopen ("/dev/ttyS0","w",stderr);
 fprintf(stdout, "This is INit Main Task");
 rtems_task_delete(RTEMS_SELF);
}

From: Sebastian Huber <sebastian.huber at embedded-brains.de>
To: rtems-users at rtems.org 
Sent: Wednesday, April 23, 2014 11:49 AM
Subject: Re: Issue with Task delete


Hello Ali,

On 2014-04-23 07:41, ali nasir wrote:
> Hi,
> In the RTEMS4.11 i notice one of the task does not delete itself cleanly via a
> call to the rtems_task_delete. On further investigation i found that the
> newlib_delete_hook does not return. The newlib_delete_hook calls a fclose and
> from this fclose, there is no return.

what do you mean with "no return".  Waits the task on a resource forever, does 
it busy wait or does the system crash (e.g. call to _Terminate())?

There is a test case for this in:

testsuites/libtests/newlib01/init.c 


>  From this particular task, we have called the frepon to redirect the to
> stdout, stdin and stderr to dev/tty0
>          freopen ("/dev/ttyS0","r",stdin);
>          freopen ("/dev/ttyS0","w",stdout);
>          freopen ("/dev/ttyS0","w",stderr);
> With the same code, the task used to get deleted cleanly with the RTEMS4.10.2
> version.
> If i remove the above lines of code from the task (with the RTEMS4.11), then
> the task gets deleted cleanly.
> This task is a higher priority task, and all further task scheduling gets
> affected if the task does not get deleted cleanly.
> Any idea what wrong do i do?

If you can send me a self contained test case, then I can try to look at it.

-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20140423/3db57353/attachment-0001.html>