X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Mon, 6 Aug 2012 10:58:17 +0200 From: Corinna Vinschen To: cygwin AT cygwin DOT com Cc: Andrey Khalyavin Subject: Re: Race condition that leads to random crashes in cygwin-based builds. Message-ID: <20120806085817.GA21876@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com, Andrey Khalyavin References: <20120724135718 DOT GA29107 AT calimero DOT vinschen DOT de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20120724135718.GA29107@calimero.vinschen.de> User-Agent: Mutt/1.5.21 (2010-09-15) Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Andrey? On Jul 24 15:57, Corinna Vinschen wrote: > On Jul 24 17:25, Andrey Khalyavin wrote: > > Hi, we have build bots that crash randomly on Windows XP and rarely on > > Windows 7. > > [...] > > Investigation of this crash dump showed that wincapc::init in > > winsup\cygwin\wincap.cc > > called api_fatal ("Cygwin requires at least Windows 2000."). This > > function is called at > > cygwin1.dll initialization even before any code in our compiler > > (cc1.exe) have been > > executed. Further investigation showed that wincapc variable is in > > shared section: > > wincapc wincap __attribute__((section (".cygwin_dll_common"), shared)); > > but wincapc::init() function doesn't have any synchronization and is called from > > dll_crt0_0 without any synchronization. Using shared variables without > > synchronization > > is sure way to get random failures. Here is one scenario that can lead > > to api_fatal called: > > [...] > > 3. First process enters wincapc::init, clears version field with > > memset and executes > > version.dwOSVersionInfoSize = sizeof (OSVERSIONINFOEX) > > 4. Task switching happens and second process enters wincapc::init. It > > sees that caps > > field is still not initialized yet and cleaders version field with memset. > > 5. Task switching happens and first process proceeds to execute > > GetVersionEx with > > version cleared by memset and so not having its size set. > > 6. GetVersionEx returns error and first process fails to start. > > > > If there is no easy way to add synchronization to wincapc::init, I > > suggest to make > > wincap a regular (not shared) variable. > > There's another way, afaics. The idea here was that wincap is only > ever set once, and even *if* the information is written twice, the > content will be identical. > > So, afaics, the above problem is a result of using memset at all. At > startup, wincap is all 0 anyway, so the memset is not required and > apparently it even hurts. Weird that nobody saw this problem before. > > I applied a patch which should fix this problem. Please give the > next developer snapshot from http://cygwin.com/snapshots/ a try, > or build yourself from CVS. Ping? Any feedback? Did you ever try a snapshot? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple