[haiku-bugs] Re: [Haiku] #13111: Possible execve bug in Haiku
- From: "bonefish" <trac@xxxxxxxxxxxx>
- Date: Wed, 14 Dec 2016 20:25:59 -0000
#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: 0 | Platform: All
----------------------------+----------------------------
Old description:
Noticed it in fish shell, below the bugreport:
https://github.com/fish-shell/fish-shell/issues/3645
Komment from ridiculousfish:
{{{
krader is right that execve is allocating memory, and I would tentatively
argue that this is a bug in Haiku. In particular POSIX requires that
execve is async-signal safe, which means it may be called from a signal
handler, and thus must not call malloc internally.
}}}
Original bugreport, for the history:
Reproduction steps
write characters into your Terminal
press Ctrl-C
Repeat
....
Profit! Fish hangs after Ctrl-C and aren't accept any input anymore, so
you need to kill it. I never had any problems like this with the 2.3.x
releases. (if i remember correctly.)
New description:
Noticed it in fish shell, below the bugreport:
https://github.com/fish-shell/fish-shell/issues/3645
Komment from ridiculousfish:
krader is right that execve is allocating memory, and I would
tentatively argue that this is a bug in Haiku. In particular POSIX
requires that execve is async-signal safe, which means it may be called
from a signal handler, and thus must not call malloc internally.
Original bugreport, for the history:
Reproduction steps
write characters into your Terminal
press Ctrl-C
Repeat
....
Profit! Fish hangs after Ctrl-C and aren't accept any input anymore, so
you need to kill it. I never had any problems like this with the 2.3.x
releases. (if i remember correctly.)
--
Comment (by bonefish):
Our `malloc()` implementation is actually async signal safe, by way of
[
http://cgit.haiku-
os.org/haiku/tree/src/system/libroot/posix/malloc/wrapper.cpp?id=b2251661bc31a3ece6ca3368e91ba2743cd02a75#n271
deferring signal delivery]. I suspect the issue in this case is rather
that `malloc()` isn't `fork()` safe in an multi-threaded program. If one
thread calls `fork()` while another is currently in `malloc()` (or
`free()`,...) the child process will inherit a locked mutex.
The solution is to register respective `atfork()` hooks for the memory
allocator. They would acquire the mutex pre-`fork()` and release it
post-`fork()`, thus ensuring that the child finds the memory allocator in
a usable state.
--
Ticket URL: <
https://dev.haiku-os.org/ticket/13111#comment:3>
Haiku <
https://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
