Race condition that leads to random crashes in cygwin-based builds.
Mon Aug 6 15:43:00 GMT 2012
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
2012/8/6 Corinna Vinschen wrote:
> 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?
> 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
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin