X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	q=dns; s=default; b=mio6pxATZTuCafAlztQgu2WC9IsqEO/LCFOqjsP3Awy
	YL6hIm84BBRDHrYrvfi3/BCj9zbKu9ieiGIRjrko0CxN/NFYHhiGkcUMIa3G+rxe
	18/Is9axrg+0Q9M00r2JKkZkwgH0AkW9JSauqHQBn5w43pXbiXl6yVkTCXUMnywM
	=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	s=default; bh=AJdV2ty7AcVImipjKBSOwHSNfsk=; b=CQMgd+FYZzqGWSHXb
	4CBTFHWfffbAykxPawZw9nd7g79uKnCU/um+flLdMCjbY+V9pUCKA5rkwhZKdKHa
	h3fA9deORPbh5St+ermTv9Srr3HVJHLGCbOsu4UocIIqFAbJzhaVBmqoOVYtdthK
	FAwZZNtx+fsL077e2oM4M0Zz1s=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.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
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2
X-HELO:	limerock03.mail.cornell.edu
X-CornellRouted:	This message has been Routed already.
Message-ID:	<53AEA23A.8030306@cornell.edu>
Date:	Sat, 28 Jun 2014 07:08:42 -0400
From:	Ken Brown <kbrown AT cornell DOT edu>
User-Agent:	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: Crash in g_file_monitor on 32-bit Cygwin
References:	<53AB82AB DOT 5000304 AT cornell DOT edu> <53ADA5B5 DOT 10404 AT cornell DOT edu> <53ADAF68 DOT 2020703 AT cygwin DOT com>
In-Reply-To:	<53ADAF68.2020703@cygwin.com>
X-IsSubscribed:	yes

On 6/27/2014 1:52 PM, Yaakov Selkowitz wrote:
> On 2014-06-27 12:11, Ken Brown wrote:
>> On 6/25/2014 10:17 PM, Ken Brown wrote:
>>> This is a followup to
>>> https://cygwin.com/ml/cygwin/2014-06/msg00324.html, from which I
>>> extracted the following test case:
>>>
>>> $ cat gfile-test.c
>>> #include <stdio.h>
>>> #include <gio/gio.h>
>>>
>>> void
>>> gfile_add_watch (const char *file)
>>> {
>>>    GFile *gfile = g_file_new_for_path (file);
>>>    GFileMonitor *monitor;
>>>    GFileMonitorFlags gflags = G_FILE_MONITOR_NONE;
>>>    monitor = g_file_monitor (gfile, gflags, NULL, NULL);
>>>    if (! monitor)
>>>      printf ("Can't watch file %s\n", file);
>>>    else
>>>      printf ("Watching file %s\n", file);
>>> }
>>>
>>> int
>>> main ()
>>> {
>>>    const char *file = "gfile-test.c";
>>>    gfile_add_watch (file);
>>> }
>>>
>>> $ gcc -g -O0 -o gfile-test $(pkg-config --cflags gio-2.0) gfile-test.c
>>> $(pkg-config --libs gio-2.0)
>>>
>>> In the 64-bit case, this behaves as expected:
>>>
>>> $ ./gfile-test.exe
>>> Watching file gfile-test.c
>>>
>>> In the 32-bit case, however, it crashes.  Running it under gdb shows
>>> that the call to g_file_monitor leads to a SEGV, but I can't tell
>>> exactly where; when I try to single step through the Glib code, I
>>> eventually hit an assertion violation in gdb.  strace shows lots of
>>> exceptions, but I can't make much sense out of it otherwise.
>>
>> I rebuilt glib and gamin without optimization so that I could step
>> through the code in gdb.  But stepping through the code turned out to be
>> unnecessary, because the bug was gone after the rebuilds.  I don't know
>> if optimization was really the issue or whether just rebuilding with the
>> latest tools is what fixed it.
>>
>> My builds can be obtained from
>>
>>    http://sanibeltranquility.com/cygwin/
>>
>> if anyone else wants to try to reproduce this without rebuilding the
>> packages themselves.
>>
>> Yaakov, could you take a look?
>
> Sure.  Are you narrow this down to only one of glib or gamin?

The culprit is gamin, and optimization *is* relevant.  What's strange, 
though, is that when I rebuild it with optimization, my test case hangs 
instead of crashing.  Summary:

- With gamin-0.1.10-14 (and its subpackages), my test case crashes.  The 
outward symptom is that there's no output, but running the test case 
under gdb shows the SEGV.

- If I rebuild gamin without optimization, I don't see any bug.  More 
precisely, I build it using your gamin.cygport with the following line 
added:

   CFLAGS+=" -O0 -g3"

- If I rebuild gamin with optimization (i.e., just using your 
gamin.cygport with no changes), my test case hangs.

Ken


--
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 -