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
