Re: [ECOS] Found problem in Thread class implementation

[Nick Garnett <nickg@calivar.com>]

On 23/05/13 11:49, Richard Rauch wrote:
> Hi,
> 
> maybe I found a problem in schedulers code....
> 
> For debugging purposes I enabled some options:
> 
> - CYGVAR_KERNEL_THREADS_LIST
> - CYGDBG_KERNEL_DEBUG_GDB_THREAD_SUPPORT
> 
> On application startup some threads should be created, but I am running in
> an exception. The reason of exception is located here:
> 
> inline void
> Cyg_Thread::add_to_list( void )
> {
>     // Add thread to housekeeping list
>     Cyg_Scheduler::lock();
> 
>     if( thread_list == 0 )
>         list_next = this;
>     else {
>         Cyg_Thread *prev = thread_list;
>         do {
>             if ( this == prev )
>                 break; // found it already!
>             prev = prev->list_next;
>         } while ( prev != thread_list );
>         if ( this != prev ) {
>             // insert it in the list:
>             list_next = thread_list->list_next;
>             thread_list->list_next = this;
>         }
>     }
>     thread_list = this;
> 
>     Cyg_Scheduler::unlock();
> }
> 
> In this loop prev becomes NULL, but there is no test on NULL, so the
> statement <NULL>->list_next causes an exception!
> Should there a test on NULL pointer only? I do not understand the reason for
> while loop condition: while (prev != thread_list). Should I compare to NULL
> here or is it more complex?

There should never be a NULL pointer in that list, it is a circular
chain through all the current threads, in no particular order, mainly
just for housekeeping. It's main use is in the GDB stubs to implement
the thread support operations.

If thread_list is NULL, the thread is just added on its own. In the
else, the do..while() looks for the current thread in the list and
breaks if found. The following if() adds the thread only if it was not
found. This part allows add_to_list() to be called more than once for
any thread; although I forget where or why this might happen.

If a NULL pointer appears here then the cause usually lies elsewhere. I
have seen it most often on thread stack overflow which writes over its
own thread object. But any memory corruption problem could cause this to
happen.


-- 
Nick Garnett                                         Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com    The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.   Tel: +44 1223 245571
Registered in England and Wales:                      Reg No: 4422071

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss