From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21362 invoked by alias); 23 May 2013 14:39:40 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 21299 invoked by uid 89); 23 May 2013 14:39:39 -0000 X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from calivar.demon.co.uk (HELO calivar.com) (83.104.54.243) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 23 May 2013 14:39:23 +0000 Received: from daikon.calivar.com (daikon.calivar.com [10.0.1.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by calivar.com (Postfix) with ESMTPS id 0A34A726C8 for ; Thu, 23 May 2013 15:39:20 +0100 (BST) Message-ID: <519E2A17.2090700@calivar.com> Date: Thu, 23 May 2013 14:39:00 -0000 From: Nick Garnett User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: ecos-discuss@ecos.sourceware.org References: <001701ce57a3$3e98cc50$bbca64f0$@itrgmbh.de> In-Reply-To: <001701ce57a3$3e98cc50$bbca64f0$@itrgmbh.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [ECOS] Found problem in Thread class implementation X-SW-Source: 2013-05/txt/msg00046.txt.bz2 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 ->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