disable thread dispatch problem

[Joel Sherrill]

Likely dispatching was still disabled and you returned to the thread
body without scheduling/dispatching to another thread. Your
thread thought it was deleted but really continued past the
pthread_exit() or rtems_task_delete() call.

You must have a Classic API task which fell off the bottom of its
body and returned. If the test is over, you need to exit().

On 07/09/2012 07:32 AM, Ashi wrote:
>
>
> 2012/7/9 Sebastian Huber <sebastian.huber at embedded-brains.de 
> <mailto:sebastian.huber at embedded-brains.de>>
>
>     On 07/09/2012 08:28 AM, Ashi wrote:
>
>
>
>         2012/7/6 Sebastian Huber <sebastian.huber at embedded-brains.de
>         <mailto:sebastian.huber at embedded-brains.de>
>         <mailto:sebastian.huber at embedded-brains.de
>         <mailto:sebastian.huber at embedded-brains.de>>>
>
>
>             On 07/06/2012 11:49 AM, Ashi wrote:
>
>                 I've a problem of _Thread_Disable_dispatch() function
>         in below code.
>                 It's my
>                 implementation of _POSIX_Keys_Run_destructors()
>         function. I come across the
>                 problem when I run the psxkey03 test:if
>         _Thread_Disable_dispatch() was
>                 commented out, psxkey03 can run without problem. when
>                 _Thread_Disable_dispatch() added at line 1(as below),
>         psxkey03 will fail. I
>                 debug it in sparc-rtems4.11-gdb, and find psxkey03
>         runs into
>                 _Internal_error_Occurred() function then stop. I know
>                 _POSIX_Keys_Get()(at line
>                 12) will also disable thread dispatch--does this lead
>         to the problem?
>                 However,
>                 can't figure out where exactly the problem exists,
>         could anyone explain
>                 it? Thanks!
>
>
>             The _Thread_Disable_dispatch() can nest.  I suppose you
>         want to acquire a
>             resource in the destructor which is not free.  The path to
>             _Internal_error_Occurred() should show the problem.
>
>         Sebastian, I follow the calls in gdb, and find the error is:
>           Program received signal SIGINT, Interrupt.
>         0x020168b8 in _Internal_error_Occurred
>         (the_source=INTERNAL_ERROR_CORE,
>         is_internal=true, the_error=5)
>              at
>         ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:58
>         58      _CPU_Fatal_halt( the_error );
>
>
>     What is the call stack here?
>
> Hi, Sebastian, the call stack is:
>
> // #0  0x020168bc in _Internal_error_Occurred 
> (the_source=INTERNAL_ERROR_CORE, is_internal=true, the_error=5) at 
> ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:58
> #1  0x0202ae58 in _Thread_Handler () at 
> ../../../../../../rtems/c/src/../../cpukit/score/src/threadhandler.c:197
> #2  0x0202acb0 in _Thread_Handler () at 
> ../../../../../../rtems/c/src/../../cpukit/score/src/threadhandler.c:89
>
> and the info local shows:
> level = 4198629
>
>     The error=5 is probably INTERNAL_ERROR_THREAD_EXITTED (see also
>     Internal_errors_Core_list).  How did you terminate the task?
>
> the task is terminated by Ctrl+C in sparc-rtems-gdb.
> However, as I said in my last post, the problem is gone when I add 
> _Thread_Enable_dispatch() at the end of each while iteration...is it 
> proper?
>
>
>     -- 
>     Sebastian Huber, embedded brains GmbH
>
>     Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
>     Phone   : +49 89 18 90 80 79-6 <tel:%2B49%2089%2018%2090%2080%2079-6>
>     Fax     : +49 89 18 90 80 79-9 <tel:%2B49%2089%2018%2090%2080%2079-9>
>     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-devel mailing list
>     rtems-devel at rtems.org <mailto:rtems-devel at rtems.org>
>     http://www.rtems.org/mailman/listinfo/rtems-devel
>
>
>
>
> -- 
> Best wishes!
> Zhongwei Yao
>


-- 
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/devel/attachments/20120709/1ff37de6/attachment-0001.html>