<div dir="ltr">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().<div><br></div><div>Is that possible?</div><div><br></div><div>-Matt</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 11, 2017 at 9:26 AM, Matthew Dillon <span dir="ltr"><<a href="mailto:dillon@backplane.com" target="_blank">dillon@backplane.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>So the question is who is doing the wait4(-1, ...)<br><div><br></div><div>-Matt</div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 11, 2017 at 9:25 AM, Matthew Dillon <span dir="ltr"><<a href="mailto:dillon@backplane.com" target="_blank">dillon@backplane.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>-Matt</div></div><div class="m_-6289744683149207290HOEnZb"><div class="m_-6289744683149207290h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 11, 2017 at 9:13 AM, Matthew Dillon <span dir="ltr"><<a href="mailto:dillon@backplane.com" target="_blank">dillon@backplane.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I assume you meant ECHILD? That would definitely be a bug if there are still children present after one exits.<div><br></div><div>-Matt</div></div><div class="m_-6289744683149207290m_73249210705233715HOEnZb"><div class="m_-6289744683149207290m_73249210705233715h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 10, 2017 at 8:29 AM, Imre Vadász <span dir="ltr"><<a href="mailto:imrevdsz@gmail.com" target="_blank">imrevdsz@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<div class="m_-6289744683149207290m_73249210705233715m_4022222676482233853HOEnZb"><div class="m_-6289744683149207290m_73249210705233715m_4022222676482233853h5"><br><br>On Monday, July 10, 2017, Imre Vadász <<a href="mailto:imrevdsz@gmail.com" target="_blank">imrevdsz@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<div>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.</div><div>Regards, Imre<br><br>On Monday, July 10, 2017, Michael Neumann <<a>mneumann@ntecs.de</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 07/10/17 15:40, Michael Neumann wrote:<br>
> Hi,<br>
><br>
> I am trying to port some Rust libraries to DragonFly, specifically the<br>
> [nix] crate to access UN*X APIs from Rust.<br>
<br>
I think it's related to the problems that can occur when fork()ing a<br>
multi-threaded program, as described here:<br>
<br>
<a href="http://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-using-them" target="_blank">http://www.linuxprogrammingblo<wbr>g.com/threads-and-fork-think-t<wbr>wice-before-using-them</a><br>
<br>
Furthermore, I think this is similar to the "cargo" issue I am seeing,<br>
when running multi-threaded (it is forking and execve "rustc" and<br>
probably doing something in between... sometimes it hangs).<br>
<br>
<br>
Regards,<br>
<br>
Michael<br>
</blockquote></div>
</blockquote>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>