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
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
Not sure this is relevant, but in compiling chromium on a Pi3 with 6 GB
of swap the job completed successfully some months ago, with peak swap
use around 3.5 GB. The swap layout was sub-optimal, with a 2 GB partition
combined with a 4 GB partition. A little over 4GB total seems usable.
A few
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
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 12 Sep, Don Lewis wrote:
> On 12 Sep, Mark Johnston wrote:
>> On Thu, Sep 12, 2019 at 04:00:17PM -0700, Don Lewis wrote:
>>> My poudriere machine is running 13.0-CURRENT and gets updated to the
>>> latest version of -CURRENT periodically. At least in the last week or
>>> so, I've been seeing
