From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3664 invoked by alias); 7 Nov 2013 01:18:48 -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 3638 invoked by uid 89); 7 Nov 2013 01:18:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50,RDNS_NONE autolearn=no version=3.3.2 X-HELO: p02c12o145.mxlogic.net Received: from Unknown (HELO p02c12o145.mxlogic.net) (208.65.145.78) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Thu, 07 Nov 2013 01:17:30 +0000 Received: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p02c12o145.mxlogic.net(mxl_mta-7.2.2-0) with ESMTP id 22aea725.0.29778.00-382.66653.p02c12o145.mxlogic.net (envelope-from ); Wed, 06 Nov 2013 18:17:30 -0700 (MST) X-MXL-Hash: 527aea2a79abb3cf-3fe1e4254235503f67e1e7e5192a5f41b2c08345 Received: from [10.186.3.231] (unknown [10.186.3.231]) by smtpauth1.linear.com (Postfix) with ESMTPSA id D0D01740B1 for ; Wed, 6 Nov 2013 17:17:20 -0800 (PST) From: Michael Jones Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9254F09D-0BE7-4FF8-A65B-9563496F1969@linear.com> Date: Thu, 07 Nov 2013 01:18:00 -0000 To: ecos discuss Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-AnalysisOut: [v=2.0 cv=D9Xw3Itj c=1 sm=1 a=glloKNylpeYNumXQcclYyA==:17 a] X-AnalysisOut: [=_sfj9nmMzCgA:10 a=D2_GN2MmYMYA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=MqDINYqSAAAA:8 a=OpZy0xLHI3cA:10 a=sxxoRUu7] X-AnalysisOut: [pknD2LM5XUIA:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-IsSubscribed: yes Subject: [ECOS] Scheduler interrupt_end starving and cause stack overflow X-SW-Source: 2013-11/txt/msg00012.txt.bz2 I am having trouble with overflowing the idle thread stack. I reduced my ap= plication down to a single thread + idle thread to test. I am using the K70 hal. The main thread is write/reading to flash, and so it uses a cond wait. All = it does is loop on writes and reads for a very long time, like a minute or = so. Basically the application uses a single thread for some initialization = of the system and I don't care if it starves other threads during startup. What happens is the idle thread and the main thread trade back and forth, b= ut eventually there is an interrupt_end. This adds some values to the stack= . And this happens multiple times. It appears that the main thread so starves the time the idle thread gets th= at eventually the calls to interrupt_end overflow the stack. This is simply= because starving the idle thread never lets it return. I can call a wait to give more time for the idle thread, or I can initializ= e before I start my threads.=20 But, does someone have a elegant solution that guarantees there is no overf= low? Seems that for a robust system you would want to ensure that if a thre= ad gets real busy due to some outside stimulus you would want to guarantee = never to overflow the idle thread. -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss