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=Eu3DA2OSzK+/qjd0Jr8IBDTx/8QmQScSgWAe0ARSRsE
	2B1gxbR774Gn+hRkO1IgSXxgJH+t8mJhf3k1IeGKVcTHaqJnneS8A5Bx0wL9wFFj
	q9e+Xikexl00G0ElG2WBCdjH56DIsrkmagi1RzJqnphDvC4Zci5/s1Zxx+iQxnA4
	=
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=FzxD/nndCPTJtgX2+5iFNLntNcw=; b=b7xyVlrDo8CFQI0F3
	7bTHE1HY2MR50gV6x1/oSfK+k/0gsqy1ertc22ikiQIvleINKI9QzXiTyllZKRCO
	fXVn+8llnNO4lY8UPBt397gKdY/3Lkaso1U9bOT7aGFfrD/eDgCqYrM1MOwex0rW
	Nl0wf6veaV/olnGsillgg2ARl4=
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,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2
X-HELO:	limerock02.mail.cornell.edu
X-CornellRouted:	This message has been Routed already.
Message-ID:	<543F1B46.2010503@cornell.edu>
Date:	Wed, 15 Oct 2014 21:11:34 -0400
From:	Ken Brown <kbrown AT cornell DOT edu>
User-Agent:	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.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> <53AEA23A DOT 8030306 AT cornell DOT edu> <543D4ED3 DOT 6020605 AT cornell DOT edu> <543D6BB9 DOT 3030009 AT cornell DOT edu> <543EA4CD DOT 4090305 AT cygwin DOT com>
In-Reply-To:	<543EA4CD.4090305@cygwin.com>
X-IsSubscribed:	yes

On 10/15/2014 12:46 PM, Yaakov Selkowitz wrote:
> On 2014-10-14 13:30, Ken Brown wrote:
>> I stepped into gam_check_not_fat (which I should have done to begin
>> with) and narrowed this down further.  The stack location in question
>> gets clobbered by the call to GetVolumeInformation:
> [snip]
>> Here's the code near the call to GetVolumeInformation, followed by what
>> I think is the relevant disassembly:
>>
>>    if (!GetVolumeInformation (root, volname, MAX_PATH, NULL,
>>                               NULL, NULL, fsname, MAX_PATH))
>>      {
>>        fprintf (stderr, "GetVolumeInformation: %d\n", GetLastError ());
>>        return 0;
>>      }
>>
>>     0x00405b3a <+840>:    movl   $0x104,0x1c(%esp) <<<<<<<<<<<<<<<<
>>     0x00405b42 <+848>:    lea    -0x120(%ebp),%eax
>>     0x00405b48 <+854>:    mov    %eax,0x18(%esp)
>>     0x00405b4c <+858>:    movl   $0x0,0x14(%esp)
>>     0x00405b54 <+866>:    movl   $0x0,0x10(%esp)
>>     0x00405b5c <+874>:    movl   $0x0,0xc(%esp)
>>     0x00405b64 <+882>:    movl   $0x104,0x8(%esp)  <<<<<<<<<<<<<<<<
>>     0x00405b6c <+890>:    lea    -0x224(%ebp),%eax
>>     0x00405b72 <+896>:    mov    %eax,0x4(%esp)
>>     0x00405b76 <+900>:    lea    -0x328(%ebp),%eax
>>     0x00405b7c <+906>:    mov    %eax,(%esp)
>>     0x00405b7f <+909>:    call   *0x41248c    <----- GetVolumeInformation?
>>     0x00405b85 <+915>:    sub    $0x20,%esp
>>     0x00405b88 <+918>:    test   %eax,%eax
>>     0x00405b8a <+920>:    jne    0x405bb5 <gam_server_create+963>
>>     0x00405b8c <+922>:    call   *0x412480    <----- GetLastError?
>>     0x00405b92 <+928>:    mov    %eax,%esi
>>     0x00405b94 <+930>:    call   0x408df0 <__getreent>
>>     0x00405b99 <+935>:    mov    %esi,0x8(%esp)
>>     0x00405b9d <+939>:    movl   $0x40c70f,0x4(%esp)
>>     0x00405ba5 <+947>:    mov    0xc(%eax),%eax
>>     0x00405ba8 <+950>:    mov    %eax,(%esp)
>>     0x00405bab <+953>:    call   0x408df8 <fprintf>
>>     0x00405bb0 <+958>:    jmp    0x406073 <gam_server_create+2177>
>>
>> Note the two marked movl instructions involving 0x104; I guess one of
>> these is the culprit, but I don't really know what's going on.
>
> While it should be purely academic now, the issue might have been a failure to
> mark pGVPN as WINAPI (IOW __stdcall on x86):
>
> -  BOOL (*pGVPN)(LPCTSTR, LPTSTR, DWORD);
> +  BOOL (WINAPI *pGVPN)(LPCTSTR, LPTSTR, DWORD);

Ah, that makes sense.  Thanks.  I'm glad to have an explanation.

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 -