Today I learned - getpid() in glibc used to cache the result (pid). This was removed in recent glibc because it was "not reliable". What? How can getpid value change over time???? https://sourceware.org/glibc/wiki/Release/2.25#pid_cache_removal …
-
-
thanks Rich. what's .
@musllibc's behavior in this regard? http://www.etalabs.net/compare_libcs.html … -
We don't cache pid and mask all signals between getpid & use of the result. But tid is cached in tcb because otherwise locks are hideously slow.
-
Difference is that most functions that use tid aren't AS-safe, meaning use in contexts where weird forkings could have invalidated them is already UB.
-
For the few that are AS-safe (raise comes to mind) we mask signals and gettid.
End of conversation
New conversation -
-
-
glibc's clone() function does update the pid/tid caches. This is why Chromium ≥43 and Firefox ≥60 (I hope) use it for sandboxing, even though it insists on calling a function on a new stack & needs a longjmp trick to recover the underlying syscall's fork()-like behavior.
-
I don't see why they care about the new function (vs returns-twice) aspect - if you're sandboxing without calling execve after forking, you're not really sandboxing because you leaked all the parent's data to the child...
-
Content/renderer processes are exec'ed, but there's also the CLONE_FS'ed chroot helper. I suppose that could all be redone with callbacks, but the longjmp hack also works. My point was mostly just that, if not for pid/tid caching, we'd just syscall(__NR_clone, ...).
End of conversation
New conversation -
-
-
Yup. I encountered some hilarity with this when running code under QEMU's user-mode emulation and forking the emulator process; if I remember correctly the emulated glibc didn't update its cached value and got very confused.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.