summaryrefslogtreecommitdiffstats
path: root/src/3rdparty/harfbuzz-ng
diff options
context:
space:
mode:
authorThiago Macieira <thiago.macieira@intel.com>2015-01-20 23:59:38 -0800
committerThiago Macieira <thiago.macieira@intel.com>2015-01-23 19:13:07 +0100
commit9931fa9df4cb96a4006a3390db64f87e3b5bc1a0 (patch)
tree3ac4a724147ec0c6f66a9c2b06e8ef80c7b4dcb5 /src/3rdparty/harfbuzz-ng
parentbd1be70e0ef665bae2c28a4f877e4a5a8268de14 (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 'src/3rdparty/harfbuzz-ng')
0 files changed, 0 insertions, 0 deletions