From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3641 invoked by alias); 2 Jan 2010 12:47:09 -0000 Received: (qmail 3633 invoked by uid 22791); 2 Jan 2010 12:47:08 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 02 Jan 2010 12:47:03 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id A38392BAB7A for ; Sat, 2 Jan 2010 07:47:01 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5+2p+CSvmxjH for ; Sat, 2 Jan 2010 07:47:01 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id A22382BAB7D for ; Sat, 2 Jan 2010 07:47:00 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id B4385F5937; Sat, 2 Jan 2010 13:46:22 +0100 (CET) Date: Sat, 02 Jan 2010 12:47:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org Subject: [RFC] GDB crash with empty executable name (MinGW) Message-ID: <20100102124622.GW548@adacore.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="cf0hFtnykp6aONGL" Content-Disposition: inline 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/msg00027.txt.bz2 --cf0hFtnykp6aONGL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 2583 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? -- Joel --cf0hFtnykp6aONGL Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0001-GDB-crash-with-empty-executable-name.patch" Content-length: 972 >From fa66afbd4e3ec9abd384ff7b2c754e4d545079e2 Mon Sep 17 00:00:00 2001 From: Joel Brobecker Date: Sat, 2 Jan 2010 13:44:04 +0100 Subject: [PATCH] GDB crash with empty executable name. * source.c (openp): Add assert that parameter string is not NULL. if parameter string is an empty string, then return with a failure immediately. --- gdb/source.c | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/gdb/source.c b/gdb/source.c index 661bbd6..9f8376a 100644 --- a/gdb/source.c +++ b/gdb/source.c @@ -707,6 +707,14 @@ openp (const char *path, int opts, const char *string, /* The open syscall MODE parameter is not specified. */ gdb_assert ((mode & O_CREAT) == 0); + gdb_assert (string != NULL); + + /* A file with an empty name cannot possibly exist. */ + if (string[0] == '\0') + { + errno = ENOENT; + return -1; + } if (!path) path = "."; -- 1.5.5.1 --cf0hFtnykp6aONGL--