Trouble with waitpid and Rust

[Matthew Dillon]

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 <dillon at 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 <dillon at 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 <dillon at 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 <imrevdsz at 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 <imrevdsz at 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 <mneumann at 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
>>>>>>
>>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20170711/178633f8/attachment-0002.html>