[ECOS] Found problem in Thread class implementation

[ECOS] Found problem in Thread class implementation

[Richard Rauch]

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?


Thanks 

Richard

ITR GmbH
web:     http://www.itrgmbh.com
email:   info@itrgmbh.com


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

Re: [ECOS] Found problem in Thread class implementation

[Nick Garnett]

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

AW: [ECOS] Found problem in Thread class implementation

[Richard Rauch]

Strange, when I disable CYGDBG_KERNEL_DEBUG_GDB_THREAD_SUPPORT, everything
works fine!
Ok, I will further debug this issue

Richard


> 
> 
> 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



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