diff options
author | Thiago Macieira <thiago.macieira@intel.com> | 2015-01-20 23:59:38 -0800 |
---|---|---|
committer | Thiago Macieira <thiago.macieira@intel.com> | 2015-01-23 19:13:07 +0100 |
commit | 9931fa9df4cb96a4006a3390db64f87e3b5bc1a0 (patch) | |
tree | 3ac4a724147ec0c6f66a9c2b06e8ef80c7b4dcb5 /tests/auto/corelib/io/qprocess/test/test.pro | |
parent | bd1be70e0ef665bae2c28a4f877e4a5a8268de14 (diff) |
Fix forkfd on OS X 10.7 and earlier
dtruss logs show that the signal handler does enter and is active, since
it does the first waitid() call, but then returns immediately:
waitid(0x0, 0x0, 0x7FFF62D7C468) = 0 0
sigreturn(0x7FFF62D7C9A0, 0x1E, 0x0) = 0 Err#-2
Since there was no error return, we conclude that si_pid was zero on
return. Source code for OS X 10.7 confirms that si_pid is set to zero
unconditionally, which is rather stupid:
http://fxr.watson.org/fxr/source/bsd/kern/kern_exit.c?v=xnu-1699.24.8#L1330
This is fixed for OS X 10.8:
http://fxr.watson.org/fxr/source/bsd/kern/kern_exit.c?v=xnu-2050.18.24#L1399
Without that information, we have to scan each child anyway, so
just disable the waitid() solution on OS X. This is a "hammer" solution
which will get forkfd working. We can later try and detect at runtime
whether waitid() is working.
Change-Id: Ic5d393bfd36e48a193fcffff13bb584927cdeafe
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Diffstat (limited to 'tests/auto/corelib/io/qprocess/test/test.pro')
0 files changed, 0 insertions, 0 deletions