As Conrad has pointed out, it's an explicit PID. The test completes
successfully when not run under truss -f.
On Fri, Sep 13, 2019 at 2:37 PM Mark Johnston wrote:
>
> On Fri, Sep 13, 2019 at 02:12:56PM -0400, Ryan Stone wrote:
> > This gets me a little further but now the wait4 call by the
On Fri, Sep 13, 2019 at 11:37 AM Mark Johnston wrote:
>
> On Fri, Sep 13, 2019 at 02:12:56PM -0400, Ryan Stone wrote:
> > This gets me a little further but now the wait4 call by the parent
> > never reaps the child and instead blocks forever:
>
> Does it perform a wildcarded wait(), or does it
On Fri, Sep 13, 2019 at 02:12:56PM -0400, Ryan Stone wrote:
> This gets me a little further but now the wait4 call by the parent
> never reaps the child and instead blocks forever:
Does it perform a wildcarded wait(), or does it explicitly specify the
PID of the child? By design, the former will
This gets me a little further but now the wait4 call by the parent
never reaps the child and instead blocks forever:
# truss -f ./pdfork -p
706: mmap(0x0,131072,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34361
970688 (0x800221000)
706: issetugid() = 0
Hello Ryan,
Can you verify is this patch fix your issue:
https://reviews.freebsd.org/D20362
Thanks,
Mariusz
On Thu, 12 Sep 2019 at 21:37, Ryan Stone wrote:
>
> I've hit an issue with a simple use of pdfork(). I have a process
> that calls pdfork() and the parent immediately does a wait4() on
