[RFC] GDB crash with empty executable name (MinGW)

Christopher Faylor cgf-use-the-mailinglist-please@sourceware.org
Sat Jan 2 19:34:00 GMT 2010


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



More information about the Gdb-patches mailing list