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

[Michael <gdb-patches@cyberfiber.org>]

I don't have my illegal copy of windows present at the moment, I'm so 
sorry I can't help you :(

Hope we can get the boost mailing-list and the gdb mailing-list on the 
same level.

Greetz,
Michael

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?
>