Message334288
> Another problem with posix_spawn() on glibc: it doesn't report errors to the parent process when run under QEMU user-space emulation and Windows Subsystem for Linux. This is because starting with commit [1] (glibc 2.25) posix_spawn() relies on address space sharing semantics of clone(CLONE_VM) to report errors, but it's not implemented in QEMU and WSL, so clone(CLONE_VM) and vfork() behave like fork(). See also [2], [3].
Oh, you know a lot of stuff about vfork and posix_spawn, you are impressive :-)
Is sys.platform equal to 'linux' on WSL? Sorry, I don't know WSL. If it's equal, is it possible to explicitly exclude WSL in the subprocess test, _use_posix_spawn()?
For QEMU, I was very surprised that a full VM wouldn't implement vfork. So I tried Fedora Rawhide and I didn't notice the bug that you described.
---
$ cat test.c
#include <spawn.h>
int main(int argc, char *argv[], char *envp[]) {
return posix_spawn(0, "non-existing", 0, 0, argv, envp);
}
$ gcc test.c
$ ./a.out
$ echo $?
2
---
In the VM, I get exit status 2 as expected.
You wrote:
---
$ aarch64-linux-gnu-gcc -static test.c
$ qemu-aarch64 ./a.out
$ echo $?
0
---
So the bug only affects "QEMU User Space". I never used that before. I understand that it's a bug in the glibc and in "QEMU User Emulation" which doesn't implement vfork "properly".
> There is no problem with musl (it doesn't rely on address space sharing).
I'm not interested to support musl at this point because I don't see any obvious way to detect that we are running musl nor get the musl version.
The history of this issue shows the posix_spawn() only works in some very specific cases, so we have to be careful and only opt-in for specific libc, on specific platform with specific libc version (read at runtime if possible). |
|
Date |
User |
Action |
Args |
2019-01-24 10:24:45 | vstinner | set | recipients:
+ vstinner, gregory.p.smith, serhiy.storchaka, koobs, izbyshev, pablogsal, nanjekyejoannah, kevans |
2019-01-24 10:24:43 | vstinner | set | messageid: <1548325483.27.0.853518629281.issue35537@roundup.psfhosted.org> |
2019-01-24 10:24:43 | vstinner | link | issue35537 messages |
2019-01-24 10:24:43 | vstinner | create | |
|