From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13287 invoked by alias); 18 Dec 2006 15:03:59 -0000 Received: (qmail 13276 invoked by uid 22791); 18 Dec 2006 15:03:58 -0000 X-Spam-Check-By: sourceware.org Received: from mail.artimi.com (HELO mail.artimi.com) (194.72.81.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 18 Dec 2006 15:03:53 +0000 Received: from rainbow ([192.168.1.165]) by mail.artimi.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Dec 2006 15:03:50 +0000 From: "Dave Korn" To: Subject: RE: CVS setup.exe crashes on Windows 2003 Server x64 Date: Mon, 18 Dec 2006 15:03:00 -0000 Message-ID: <029f01c722b5$b9d46d40$a501a8c0@CAM.ARTIMI.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <297343D29C14AA4D822142893ABEAEF302836DA8@srv1163ex1.flightsafety.com> 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/msg00060.txt.bz2 On 18 December 2006 14:45, Thrall, Bryan wrote: > Dave Korn wrote on Friday, December 15, 2006 7:13 PM: >> On 15 December 2006 21:08, Thrall, Bryan wrote: >> >>> I'm seeing setup.exe built from CVS head crash on Windows 2003 Server >>> x64 (Standard version, SP 1). >> >>> Program received signal SIGSEGV, Segmentation fault. >>> 0x004eb157 in AllocateAndInitializeSid@44 () >>> (gdb) bt >>> #0 0x004eb157 in AllocateAndInitializeSid@44 () >>> #1 0x0043d8f8 in NTSecurity::initialiseEveryOneSID (this=0x23f780) >>> at main.cc:269 #2 0x0043daca in NTSecurity::setDefaultDACL >>> (this=0x23f780) at main.cc:287 #3 0x0043e1ec in >>> NTSecurity::setDefaultSecurity (this=0x23f780) at main.cc:340 #4 >>> 0x0043ed33 in set_default_sec () at main.cc:237 #5 0x0043f3a2 in >>> WinMain (h=0x400000, hPrevInstance=0x0, command_line=0xe0245d >>> "", cmd_show=10) at main.cc:482 #6 0x00499238 in main (argc=1, >>> argv=0x346b8, __p__environ=0x33090) at ../../runtime/main.c:73 >>> >>> 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). > Sorry, I meant to say that the this pointer is fine in > NTSecurity::setDefaultDACL (frame 2), but bad in > NTSecurity::initialiseEveryOneSID (frame 1). 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. 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? >> Don't have 64bits or 2k3 but I'll see how win2k likes it. 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. cheers, DaveK -- Can't think of a witty .sigline today....