#13111: Possible execve bug in Haiku
----------------------------+----------------------------
Reporter: miqlas | Owner: axeld
Type: bug | Status: assigned
Priority: normal | Milestone: Unscheduled
Component: System/POSIX | Version: R1/Development
Resolution: | Keywords:
Blocked By: | Blocking:
Has a Patch: 1 | Platform: All
----------------------------+----------------------------
Comment (by bonefish):
At a quick glance both patches look okay. While the `pthread_atfork()`
solution would be a bit more elegant from a software design point of view
I'd rather go with the first patch for sake of robustness -- even if the
memory allocator is the first to register a hook ATM, this might change
later and possibly reintroduce the issue. I would move the
`__heap_after_fork_child()` call before
`__reinit_pwd_backend_after_fork()`, though (the memory allocator won't
ever use the user/group API, but the user/group API implementation uses
memory allocations (even if the hook doesn't ATM)).
One other issue I noticed is that `fork()` is supposed to be async signal
safe, but our implementation is not. The reason being the use of
`sForkLock`. We should defer signals before we acquire `sForkLock` in
`__register_atfork` and probably also in `fork()`.
--
Ticket URL: <https://dev.haiku-os.org/ticket/13111#comment:8>
Haiku <https://dev.haiku-os.org>
Haiku - the operating system.