This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] GDB crash with empty executable name (MinGW)
- From: Christopher Faylor <cgf-use-the-mailinglist-please at sourceware dot org>
- To: gdb-patches at sourceware dot org, Joel Brobecker <brobecker at adacore dot com>
- Date: Sat, 2 Jan 2010 14:33:46 -0500
- Subject: Re: [RFC] GDB crash with empty executable name (MinGW)
- References: <20100102124622.GW548@adacore.com>
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 <Address 0xffffffff out of bounds>, _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 <sys/types.h>
> | #include <sys/stat.h>
> | #include <unistd.h>
> | #include <stdlib.h>
> | #include <stdio.h>
> |
> | 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 <brobecker@adacore.com>
>
> * 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