delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2012/08/06/11:31:45

X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-6.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,T_RP_MATCHES_RCVD
X-Spam-Check-By: sourceware.org
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-system-of-record:x-gm-message-state; bh=IG5x0NLJn5Rcw7uxDtAMIPWfRLp/ixCAx2h2O7ZlKSs=; b=LY1C0fmDdydgq4T9iFbwMpS5I1ueZSJhTuFnMf1i6LDZcKvsm73tYgNtyHf4v06t6c LgR9wDaqRWq1s6qgu8xBmd5FjzLKl9ALlHvjzWKV+6oomR0jeGLQuMCxiW8fobx5ezVS kGrFnPuJyzLt/GxrQOcLZx+EG+4VAHtVl48u09Bc4Yeortdkrxg3GYkKQtGmvO0t8CVl yiwZoNlhQGsVZKKAqlQVGepviH+QVqO+XCFQYPawGZ4ZmgQVAuIl1I/xv42m+sDxlYfG Xfgso9b8UALsiz6XbtXtAaG1Nx0qHaf9TdPilpJ332YB+Rj2qHVPNeq8T/pnSHgKajD8 W1Fw==
MIME-Version: 1.0
In-Reply-To: <20120806085817.GA21876@calimero.vinschen.de>
References: <CACgPhYpV-M477Mfugp3DjdWCEvbJ-8LhyH12y=iGP_MuK6VTAQ AT mail DOT gmail DOT com> <20120724135718 DOT GA29107 AT calimero DOT vinschen DOT de> <20120806085817 DOT GA21876 AT calimero DOT vinschen DOT de>
Date: Mon, 6 Aug 2012 19:31:18 +0400
Message-ID: <CACgPhYru7WdRfuTtyzXcq0Q5=wUZeiUn+n1a4UOdq7psASUjFw@mail.gmail.com>
Subject: Re: Race condition that leads to random crashes in cygwin-based builds.
From: Andrey Khalyavin <halyavin AT google DOT com>
To: cygwin AT cygwin DOT com
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQlYTc+uJ2jZtcXhal1EmBmntWlVqohtEkbIyhsdgvyX6+ylrkrB6XRodBbTD9UGC0AjwOBhAlkYZbawitg3IqQuQzIooeZz4jGvxlUd5p5323w1dC8MfrjhxLpCGfHJwWGknRNIDPlunmrJExWQ6rQN2bXVokzzbgC+J7fWSOmPZo+I3lpNACGN+3ZGx39RkaXmb68k
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

I updated our cygwin with core libraries from 20120725 snapshot. There
are still crashes in our build, I'm investigating them. Haven't got a
crash dump yet. This time I have to catch them on the bots instead of
local computer.

Andrey Khalyavin

2012/8/6 Corinna Vinschen wrote:
> 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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019