Project

General

Profile

Actions

Bug #17189

closed

Updated by dalias (Rich Felker) over 4 years ago

From my reading of the test source, it seems to be testing the ability to do various async-signal-unsafe things after fork (but without execve) from a multithreaded parent, which has undefined behavior. Does Ruby (and Ruby programs) actually depend on the ability to do this, or is it just a gratuitous test for something that's not supposed to be supported usage. It looks dubious to me that Ruby even exposes a fork operation to the program it's executing; it's really hard to get forking of an interpreter right, and basically impossible if the interpreter process is allowed to be multi-threaded.

Updated by jeremyevans0 (Jeremy Evans) over 4 years ago

  • Status changed from Open to Feedback

Can you narrow down which particular test method is causing this issue? That would help narrow down the problem? Even if the problem is not fixable, we could skip that test on musl libc so the test suite doesn't deadlock.

It is expected to be able to fork without execve and have child processes perform useful work, and this is commonly used, with some Ruby webservers such as Unicorn working this way by default. fork is supposed to work even if the parent has other threads at the time of forking (other threads will be dead in the child process, though).

Updated by jeremyevans0 (Jeremy Evans) almost 4 years ago

  • Status changed from Feedback to Closed

Updated by hsbt (Hiroshi SHIBATA) about 1 year ago

  • Tags set to musl, alpine
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0