delorie.com/archives/browse.cgi | search |
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:date:from:to:subject:message-id:reply-to | |
:references:mime-version:content-type:in-reply-to; q=dns; s= | |
default; b=d9gLUJv6NQpSC2fqtYDy/0hKA6k+Q9Dgmw7lEsDHgoozgJkjUnHis | |
tPk0dBcl3guEx6UV8ZBov7xPYL+D8mJjaX4/Mpx8GG4joSw7/1FBT2/yxyX0LOVt | |
18nY22FKqMMloit0Sq3NThdg+7cyY1Vm9sXe7XS/mQcAlmf/lfCTcw= | |
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:date:from:to:subject:message-id:reply-to | |
:references:mime-version:content-type:in-reply-to; s=default; | |
bh=Pt+9by+Z85xMXsrvuisc6sEAM1g=; b=Cu5+IfO04VnfkMPIzUf98DD5pI02 | |
hC5KleRI66fkp3Yggyf+joryYjVTE+8M328qEsGcPVyntYX8KovSApX2626QKDJp | |
tz+Z/4RQHIPQEwHKvfWjXkRaCTvHOHjxLwb5OO9GYyC0PdavMw05Ltlf7xsQteTw | |
xAXwsZB8rFs1bEM= | |
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=-5.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 |
X-HELO: | calimero.vinschen.de |
Date: | Tue, 14 Oct 2014 21:28:03 +0200 |
From: | Corinna Vinschen <corinna-cygwin AT cygwin DOT com> |
To: | cygwin AT cygwin DOT com |
Subject: | Re: Crash in g_file_monitor on 32-bit Cygwin |
Message-ID: | <20141014192803.GE2681@calimero.vinschen.de> |
Reply-To: | cygwin AT cygwin DOT com |
Mail-Followup-To: | cygwin AT cygwin DOT com |
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> |
MIME-Version: | 1.0 |
In-Reply-To: | <543D6BB9.3030009@cornell.edu> |
User-Agent: | Mutt/1.5.23 (2014-03-12) |
--53AZ357FMu84hmXL Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Ken, I know the code is not yours, but I have to vent while I see this code :) On Oct 14 14: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: >=20 > (gdb) s > gam_check_not_fat (path=3D0x8005c068 "/tmp/fam-kbrown") > at /usr/src/debug/gamin-0.1.10-16/server/gam_channel.c:35 > 35 cygwin_conv_path(CCP_POSIX_TO_WIN_A, path, winpath, MAX_PATH); Ouch. What about paths longer than MAX_PATH? > (gdb) x/x $ebp-0x510 > 0x28a6a8: 0x8005c068 > (gdb) n > 37 pGVPN =3D GetProcAddress(LoadLibrary("kernel32"), "GetVolumePat= hNameA"); There's no reason to load GetVolumePathName from kernel32 since all support= ed platforms provide this entry point. > (gdb) x/x $ebp-0x510 > 0x28a6a8: 0x8005c068 > (gdb) n > 38 if (!pGVPN || !(pGVPN)(winpath, root, MAX_PATH)) > (gdb) x/x $ebp-0x510 > 0x28a6a8: 0x8005c068 > (gdb) n > 52 if (!GetVolumeInformation (root, volname, MAX_PATH, NULL, > (gdb) x/x $ebp-0x510 > 0x28a6a8: 0x8005c068 > (gdb) n > 58 if (!strncmp(fsname, "FAT", 3)) /* FAT, FAT32 */ How old is this code? What *exactly* is this function trying to check? I assume it's checking for certain filesystem capabilities, but then, there's no good reason to check for a filesystem being "FAT" or "FAT32". Any other filesystem might have the same or similar capabilities and be called "FOOBAR". Whatever the code is doing, it should probably simply call statvfs() and check the f_flag member of the returned struct statvfs for a certain flag. The flags returned in f_flag are the same as the fs flags returned by GetVolumeInformation. So, what is it the code is trying to test by checking the FS name? Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --53AZ357FMu84hmXL Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUPXlDAAoJEPU2Bp2uRE+gIwUP/1MAdVmOfaW72SoKLU9rdEXM 4DfDRPKasNZmGadDwONcXeQbP2XuCrJctg8cGMDv40YQv297BEbMHHkL+jo1Ty4s 0BrouJByDOhWuYYYbpmJYAdDTK47NjaiRyBf4KpuIxxw84PMarEoQ2ZEPPzs2ivw A6jdTrzyl8i/LBjy9ugsyDdan9snW/i/T7+gcX6GVKd/agG5c8fDZ2hoO3EDpQmk o1aGjH9dAx59LNO0piQv6BA5QJVNhuo1R0WNdJxC2FXXPFn9P/6Bj4BnO2MJxlLO mUb3lR2p47v78yudBQpGsZt68QhWoJupW8VVcqxqSEjUbI8BsCBPoahU/zI4XD4j pLO79lbvQWvz8Q575r43DqGWRtMJaZpI5WUby+Wiw6Vi5JNfNPf1bUE3fgM9EVTr ar4PFBnfiM2bsnsoh14wAdAi9tywzbr+2td0vWd3ewafNhYTzvbhHi5uXDQVEiSK JbbuPM5hK0vZWmiT2APUs8L7D4j06jlz5/aJnz8PNBj4zPGVdiSIvg8bG2VL6Mvn J2vuhn8z6T7G0IYplltoHo1B+1wXcNFR/ljS6ywHqVOI4xxNcPntXNwYdXmu9n3f ypTmAJ22dVlYKSW0HnAEkFBc57ZajH80L7w8gsYxkcknwhQFrCaPvCiX+KclDtdr CQGYaDEXLaBSbYOnMITg =JHX3 -----END PGP SIGNATURE----- --53AZ357FMu84hmXL--
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |