* [ECOS] Found problem in Thread class implementation
@ 2013-05-23 10:49 Richard Rauch
2013-05-23 14:39 ` Nick Garnett
0 siblings, 1 reply; 3+ messages in thread
From: Richard Rauch @ 2013-05-23 10:49 UTC (permalink / raw)
To: ecos-discuss
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [ECOS] Found problem in Thread class implementation
2013-05-23 10:49 [ECOS] Found problem in Thread class implementation Richard Rauch
@ 2013-05-23 14:39 ` Nick Garnett
2013-05-24 5:13 ` AW: " Richard Rauch
0 siblings, 1 reply; 3+ messages in thread
From: Nick Garnett @ 2013-05-23 14:39 UTC (permalink / raw)
To: ecos-discuss
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* AW: [ECOS] Found problem in Thread class implementation
2013-05-23 14:39 ` Nick Garnett
@ 2013-05-24 5:13 ` Richard Rauch
0 siblings, 0 replies; 3+ messages in thread
From: Richard Rauch @ 2013-05-24 5:13 UTC (permalink / raw)
To: 'Nick Garnett', ecos-discuss
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-05-24 5:13 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-05-23 10:49 [ECOS] Found problem in Thread class implementation Richard Rauch
2013-05-23 14:39 ` Nick Garnett
2013-05-24 5:13 ` AW: " Richard Rauch
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).