Trouble with waitpid and Rust

[Imre Vadász]

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
> <javascript:_e(%7B%7D,'cvml','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-
>> twice-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/20170710/b0ed0b06/attachment-0002.html>