Why would a cygwin program lose path prefix when running under gdb? - debugging

Question

I just came to a really strange problem with gdb with a relatively large software build in Cygwin64 on Windows 10, which I cannot really reproduce with a minimal example.
So, let me first provide a minimal example that works fine (and does not reproduce the error): basically, the below code (test_cygwin.cpp) just wants to create exclusive access file in /var/run.
Let's recall that /var/run is a Unix path, and as such does not exist in Windows; otherwise it is mapped to the Windows filesystem through a directory in the Cygwin installation:
$ cygpath -w /var/run
C:\cygwin64\var\run
Here is test_cygwin.cpp:
// compile with:
// g++ test_cygwin.cpp -g -o test_cygwin.exe
#include <iostream> // cout
#include <errno.h> // errno
#include <string.h> // strerror
#include <fcntl.h> // open
#include <unistd.h> // close
int main(void) {
std::string filepath("/var/run/test");
std::cout << "opts: " << O_RDWR << " | " << O_CREAT << " | " << O_EXCL << " , " << S_IRUSR << " | " << S_IWUSR << " | " << S_IRGRP << " | " << S_IWGRP << " | " << S_IROTH << " | " << S_IWOTH << std::endl;
int my_fd = open(filepath.c_str(), O_RDWR | O_CREAT | O_EXCL, S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH);
if (my_fd < 0) {
std::cout << "Failed to open " << filepath << ": " << strerror(errno) << std::endl;
return 1;
}
std::cout << "Opened " << filepath << std::endl;
close(my_fd);
return 0;
}
So, basically, if I run this program and the file does not exist, the file is created; if the file exists, the program reports an error - in Cygwin's bash shell:
user#DESKTOP-COMPUTER /tmp
$ ls -la /var/run/test
ls: cannot access '/var/run/test': No such file or directory
user#DESKTOP-COMPUTER /tmp
$ ./test_cygwin.exe
opts: 2 | 512 | 2048 , 256 | 128 | 32 | 16 | 4 | 2
Opened /var/run/test
user#DESKTOP-COMPUTER /tmp
$ ls -la /var/run/test
-rw-r--r-- 1 user None 0 Oct 8 14:38 /var/run/test
user#DESKTOP-COMPUTER /tmp
$ ./test_cygwin.exe
opts: 2 | 512 | 2048 , 256 | 128 | 32 | 16 | 4 | 2
Failed to open /var/run/test: File exists
user#DESKTOP-COMPUTER /tmp
$ rm /var/run/test && ls -la /var/run/test
ls: cannot access '/var/run/test': No such file or directory
Ok, so far so good. Now, the opts are printed out, so that I could re-run the open command from within a gdb session; again in Cygwin bash:
$ gdb --args ./test_cygwin.exe
GNU gdb (GDB) (Cygwin 10.2-1) 10.2
...
Reading symbols from ./test_cygwin.exe...
(gdb) b test_cygwin.cpp:13
Breakpoint 1 at 0x1004011f2: file test_cygwin.cpp, line 13.
(gdb) r
Starting program: /tmp/test_cygwin.exe
[New Thread 12044.0x467c]
[New Thread 12044.0x4f8]
[New Thread 12044.0x280]
[New Thread 12044.0x9b4]
opts: 2 | 512 | 2048 , 256 | 128 | 32 | 16 | 4 | 2
Thread 1 "test_cygwin" hit Breakpoint 1, main () at test_cygwin.cpp:13
13 int my_fd = open(filepath.c_str(), O_RDWR | O_CREAT | O_EXCL, S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH);
(gdb) p (int)open("/var/run/test", 2 | 512 | 2048 , 256 | 128 | 32 | 16 | 4 | 2)
[New Thread 12044.0x42a0]
[New Thread 12044.0x2ff8]
$1 = 3
(gdb) p (int)open("/var/run/test", 2 | 512 | 2048 , 256 | 128 | 32 | 16 | 4 | 2)
$2 = -1
(gdb) c
Continuing.
Failed to open /var/run/test: File exists
[Thread 12044.0x1c14 exited with code 1]
[Thread 12044.0x9b4 exited with code 1]
[Thread 12044.0x280 exited with code 1]
[Thread 12044.0x4f8 exited with code 1]
[Thread 12044.0x42a0 exited with code 1]
[Thread 12044.0x2ff8 exited with code 1]
Program terminated with signal SIGHUP, Hangup.
The program no longer exists.
(gdb) quit
So, in the above snippet, the breakpoint halts the program right before it attempts to open the file, and the file is created manually by running p (int)open("/var/run/test", 2 | 512 | 2048 , 256 | 128 | 32 | 16 | 4 | 2) in the gdb shell.
The first invocation of this command in the gdb shell succeeds (3 is returned, as the numeric file descriptor of the newly opened file); the second fails (-1 is returned) - and when the program proceeds, it clearly fails, as the requested file exists already.
So far, so good - all is as expected.
Now, here is the problem I have in my actual build - which I cannot reproduce here:
When I run the program normally (e.g. ./myprogram.exe --arg1=1 ...), the open call succeeds
When I run the program via gdb (that is, gdb --args ./myprogram.exe --arg1=1 ...), the open call always fails, with "No such file or directory"
So, similar to the above, I placed a breakpoint right before that open command in the actual program, and I've tried (making sure I've deleted rm /var/run/test at start):
(gdb) p (int)open("/var/run/test", 2 | 512 | 2048 , 256 | 128 | 32 | 16 | 4 | 2)
$27 = -1
(gdb) p (int)open("/var/run/test", 2 | 512 | 2048 , 256 | 128 | 32 | 16 | 4 | 2)
$28 = -1
Yup, so it fails already at very start; however, if I now add the cygdrive prefix:
(gdb) p (int)open("/cygdrive/c/cygwin64/var/run/test", 2 | 512 | 2048 , 256 | 128 | 32 | 16 | 4 | 2)
$29 = 26
(gdb) p (int)open("/cygdrive/c/cygwin64/var/run/test", 2 | 512 | 2048 , 256 | 128 | 32 | 16 | 4 | 2)
$30 = -1
... then it succeeds, from within gdb?!?! And indeed, the Cygwin bash shell also sees this file afterwards:
$ ls -la /var/run/test
-rw-r--r-- 1 user None 0 Oct 8 14:50 /var/run/test
Recalling the error message from the first example: if I want to create a file (/var/run/test) with open, and I get "No such file or directory" error - I interpret that as the parent directory (here /var/run) not existing, at least from the perspective of the program.
So, in this particular case, when gdb debugs this particular myprogram.exe, it has somehow "lost" the reference to root Unix paths (I've confirmed that also creating a file in /tmp fails in this case); or in other words, the program in gdb cannot see these paths (and so these paths don't exist for this program) - however, it can still access the same folder locations, and successfully open/create a file, by having the Cygwin installation path prefixed.
The strange thing being, that /cygdrive is also a Unix path formulation, albeit specific to Cygwin?! Also, interestingly, even when debugging this program, I can "see" these directories from gdb itself:
(gdb) cd /var/run
Working directory /var/run.
(gdb) pwd
Working directory /var/run.
... so, gdb in itself still "sees" these directories - even if the debuggee program does not?!
So, my question is: while the minimal example clearly shows that this is not a general issue with gdb in Cygwin - has anyone ever experienced, that a Cygwin program "loses reference" to (or "cannot see") Unix system paths when running in gdb; but otherwise sees these paths fine when running directly from the Cygwin bash shell?
If so, would anyone have an explanation why does this situation occur - and how to rectify it (that is, make the open succeed, also when the program runs under gdb - just as well as when the program runs standalone in the Cygwin bash shell)?
(just as a clarification note on why I want to know this: the actual program I'm debugging segfaults after the open call, which I'd like to catch in gdb; however, since the open call fails in gdb, the program under gdb currently cannot even get to the point that otherwise segfaults).