From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23894 invoked by alias); 2 Jan 2010 19:34:03 -0000 Received: (qmail 23885 invoked by uid 22791); 2 Jan 2010 19:34:03 -0000 X-Spam-Check-By: sourceware.org Received: from pool-173-76-52-118.bstnma.fios.verizon.net (HELO cgf.cx) (173.76.52.118) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 02 Jan 2010 19:33:55 +0000 Received: from ednor.cgf.cx (ednor.casa.cgf.cx [192.168.187.5]) by cgf.cx (Postfix) with ESMTP id 1633413C0C7; Sat, 2 Jan 2010 14:33:46 -0500 (EST) Received: by ednor.cgf.cx (Postfix, from userid 201) id 0B26E2B35A; Sat, 2 Jan 2010 14:33:46 -0500 (EST) Date: Sat, 02 Jan 2010 19:34:00 -0000 From: Christopher Faylor To: gdb-patches@sourceware.org, Joel Brobecker Subject: Re: [RFC] GDB crash with empty executable name (MinGW) Message-ID: <20100102193345.GC8480@ednor.casa.cgf.cx> Mail-Followup-To: gdb-patches@sourceware.org, Joel Brobecker References: <20100102124622.GW548@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100102124622.GW548@adacore.com> User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-01/txt/msg00029.txt.bz2 On Sat, Jan 02, 2010 at 04:46:22PM +0400, Joel Brobecker wrote: >I happened to notice this by accident, because of a bug in our testsuite >that caused us to spawn GDB as ... > > % gdb "" > >... instead of ... > > % gdb > >... when we want to start GDB without an executable name. The atypical >command where we launch GDB with an empty exec name causes the crash >on only one of our Windows machines (Win XP 32bit to be exact). To >reproduce: > > % gdb "" > [...] > : No such file or directory. > (gdb) set height 0 > Critical error handler: process 2496 (c:\[...]\gdb.exe) > terminated due to access violation > >It looks like a MinGW bug - while debugging this, GDB receives a SIGTRAP >notification from ntdll: > > (gdb) step > warning: HEAP[toto.exe]: > warning: Heap block at 003E2460 modified at 003E2492 past requested size of 2a > > Program received signal SIGTRAP, Trace/breakpoint trap. > 0x7c91120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll > >The backtrace shows that we're in _mingw_stat and that the _path has >changed from something sensible (the current working directory with a slash >at the end) to something obviously wrong: > > #8 0x0040193b in _mingw_stat ( > _path=0xffffffff
, _st=0x22ff38) > at stat.c:71 > >I can reproduce the same SIGTRAP debugging the following little C program, >even if that little program does not crash. > > | #include > | #include > | #include > | #include > | #include > | > | int > | main (void) > | { > | struct stat st; > | const int status = stat ("c:\\[...]\\bin/", &st); > | void *m; > | > | m = malloc (16); > | printf ("status = %d\n", status); > | free (m); > | return (m == NULL); > | } > >I can't confirm that this is a bug though, I haven't been able to find >the assocated file in the MinGW website (file stat.c, around line 71), >and I gave up since. However, I think it's also reasonable to have >a short circuit that immediately returns an error if the file we are >trying to open is empty. If anything this is a minor optimization. > >2009-01-02 Joel Brobecker > > * source.c (openp): Add assert that parameter string is not NULL. > if parameter string is an empty string, then return with a failure > immediately. > >I have not bothered testing it yet, but I will before checking it in, >if there are no objections. Given how rare it must be to call GDB with >an empty executable name, I do not think that this is a very critical patch. > >Anyone in favor? Given that this is apparently a mingw (or Windows???) bug your fix makes sense to me. cgf