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?