From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8196 invoked by alias); 18 Dec 2006 15:39:50 -0000 Received: (qmail 8185 invoked by uid 22791); 18 Dec 2006 15:39:48 -0000 X-Spam-Check-By: sourceware.org Received: from mailgw01n.flightsafety.com (HELO mailgw01n.flightsafety.com) (66.109.90.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 18 Dec 2006 15:39:39 +0000 Received: from mailgw01n.flightsafety.com (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BF4AF98C75 for ; Mon, 18 Dec 2006 10:39:58 -0500 (EST) Received: from VXS2.flightsafety.com (internal-31-146.flightsafety.com [192.168.31.146]) by mailgw01n.flightsafety.com (Postfix) with ESMTP id 6603498C81 for ; Mon, 18 Dec 2006 10:39:57 -0500 (EST) Received: from srv1163ex1.flightsafety.com ([198.51.28.39]) by VXS2.flightsafety.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Dec 2006 10:39:33 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: CVS setup.exe crashes on Windows 2003 Server x64 Date: Mon, 18 Dec 2006 15:39:00 -0000 Message-ID: <297343D29C14AA4D822142893ABEAEF302836E2C@srv1163ex1.flightsafety.com> From: "Thrall, Bryan" To: X-IsSubscribed: yes Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com X-SW-Source: 2006-12/txt/msg00061.txt.bz2 Dave Korn wrote on Monday, December 18, 2006 9:04 AM: > On 18 December 2006 14:45, Thrall, Bryan wrote: >=20 >> Dave Korn wrote on Friday, December 15, 2006 7:13 PM: >>> On 15 December 2006 21:08, Thrall, Bryan wrote: >>>=20 >>>> I'm seeing setup.exe built from CVS head crash on Windows 2003 >>>> Server x64 (Standard version, SP 1). >>>=20 >>>> Program received signal SIGSEGV, Segmentation fault. >>>> 0x004eb157 in AllocateAndInitializeSid@44 () >>>> (gdb) bt >>>> #0 0x004eb157 in AllocateAndInitializeSid@44 () >>>> #1 0x0043d8f8 in NTSecurity::initialiseEveryOneSID (this=3D0x23f780) >>>> at main.cc:269 #2 0x0043daca in NTSecurity::setDefaultDACL >>>> (this=3D0x23f780) at main.cc:287 #3 0x0043e1ec in >>>> NTSecurity::setDefaultSecurity (this=3D0x23f780) at main.cc:340 #4 >>>> 0x0043ed33 in set_default_sec () at main.cc:237 #5 0x0043f3a2 in >>>> WinMain (h=3D0x400000, hPrevInstance=3D0x0, command_line=3D0xe0245d >>>> "", cmd_show=3D10) at main.cc:482 #6 0x00499238 in main (argc=3D1, >>>> argv=3D0x346b8, __p__environ=3D0x33090) at ../../runtime/main.c:73 >>>>=20 >>>> After a little debugging, it looks like the this pointer is getting >>>> corrupted between frames 1 and 0 (it is valid in frame 1 and >>>> invalid -- 0x105 IIRC -- in frame 0). >=20 >> Sorry, I meant to say that the this pointer is fine in >> NTSecurity::setDefaultDACL (frame 2), but bad in >> NTSecurity::initialiseEveryOneSID (frame 1). >=20 > Oh well, that blows out my theory you might have been getting > linked against the wrong version of the libs (64-vs-32 bit) and hence > get disagreements about sizes of various integer types being passed > on the stack as arguments.=20 >=20 > Wait a minute! That stack trace shows 'this as having the same > value in frames 1, 2 and 3, it's 0x23f780 in all of them. That > suggests that gdb is parsing the stack right and the code is getting > it wrong. I think you still need to worry about sizes of stack > arguments. Maybe there's a header file somewhere that uses an int > where it should have written long int, and nobody's noticed until > LP64 made them become different sizes?=20 Er... why yes it certainly does! Don't know how I missed that... Ok, I checked just to be sure, and if I set a breakpoint on main:269, then the this pointer is invalid (0x105) in NTSecurity::initialiseEveryOneSID; after the segfault, the this pointer is valid again (0x23f780). Weird. Also, I rebooted the machine this morning, and got a bunch of message popups dated from my last test session regarding DEP. This seems like a big clue that Windows DEP is trying to close setup.exe, which is causing this crash. It seems extremely odd that the "DEP is closing your process" messages wouldn't pop up until you reboot, though. ... And in fact, disabling DEP for setup.exe fixes the problem. So, it looks like setup.exe is trying to execute some memory that Windows thinks it shouldn't be (the invalid this pointer, probably, but why then is it invalid at that point and valid after the segfault?). >>> Don't have 64bits or 2k3 but I'll see how win2k likes it. >=20 > Haven't tested this yet owing to wanting to keep my installation > stable while doing gcc testsuite runs. Should be able to give it a > go tonight or tomorrow. >=20 >=20 > cheers, > DaveK --=20 Bryan Thrall FlightSafety International Bryan.Thrall@flightsafety.com