If test_wait() and test_fork_and_waitpid() are running simultaneously from different threads, then test_wait() can reap the pid that test_fork_and_waitpid() is explicitly waiting on. Because test_wait() is using a generic non-specific wait().
Is that possible? -Matt On Tue, Jul 11, 2017 at 9:26 AM, Matthew Dillon <dil...@backplane.com> wrote: > Er, what I meant to say, the thread doing the wait4(-1, ...) is returning > the pid that the second thread doing the wait4(pid, ...) was explicitly > waiting for. So that second thread properly returns ECHILD. > > So the question is who is doing the wait4(-1, ...) > > -Matt > > On Tue, Jul 11, 2017 at 9:25 AM, Matthew Dillon <dil...@backplane.com> > wrote: > >> Ok, I'm not sure this is a bug in DragonFly. When I ktrace -i the test >> program threaded, another thread is doing a wait4(-1, ...) at the same as >> the thread doing wait4(specific_pid, ...). The specific pid is being >> repeated by the thread doing the wait4(-1, ...), so the thread doing the >> wait4(specific_pid, ...) doe sproperly return SIGCHLD in that situation. >> >> -Matt >> >> On Tue, Jul 11, 2017 at 9:13 AM, Matthew Dillon <dil...@backplane.com> >> wrote: >> >>> I assume you meant ECHILD? That would definitely be a bug if there are >>> still children present after one exits. >>> >>> -Matt >>> >>> On Mon, Jul 10, 2017 at 8:29 AM, Imre Vadász <imrev...@gmail.com> wrote: >>> >>>> Ok, not related to SIGCHLD or anything like that. What I see when >>>> running that binary, is that 2 threads are blocking in wait() and when a >>>> child exit()s, one wait successfully returns. But the other one erronously >>>> reports SIGCHLD instead of continuing to block as would be expected. This >>>> definitely looks like a bug in the wait4 syscall, judging from the trace I >>>> got with "ktrace -i ./test-nix --test-threads 4" here. >>>> >>>> >>>> On Monday, July 10, 2017, Imre Vadász <imrev...@gmail.com> wrote: >>>> >>>>> Hi, >>>>> Did you verify that the child isn't just exiting before the parent >>>>> calls wait(), and getting reaped by a signal handler for SIGCHLD? This >>>>> should be easy to verify by running the binary with ktrace. In that case >>>>> getting ECHILD from waitpid() would be perfectly fine and could be treated >>>>> as success. >>>>> Regards, Imre >>>>> >>>>> On Monday, July 10, 2017, Michael Neumann <mneum...@ntecs.de> wrote: >>>>> >>>>>> >>>>>> >>>>>> On 07/10/17 15:40, Michael Neumann wrote: >>>>>> > Hi, >>>>>> > >>>>>> > I am trying to port some Rust libraries to DragonFly, specifically >>>>>> the >>>>>> > [nix] crate to access UN*X APIs from Rust. >>>>>> >>>>>> I think it's related to the problems that can occur when fork()ing a >>>>>> multi-threaded program, as described here: >>>>>> >>>>>> http://www.linuxprogrammingblog.com/threads-and-fork-think-t >>>>>> wice-before-using-them >>>>>> >>>>>> Furthermore, I think this is similar to the "cargo" issue I am seeing, >>>>>> when running multi-threaded (it is forking and execve "rustc" and >>>>>> probably doing something in between... sometimes it hangs). >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Michael >>>>>> >>>>> >>> >> >
