cvs commit: ports UPDATING ports/mail/enigmail Makefile distinfo pkg-message ports/mail/enigmail-thunderbird Makefile

[Andriy Gapon]

on 19/08/2011 18:35 Andriy Gapon said the following:
> on 19/08/2011 18:28 Andriy Gapon said the following:
>> So apparently there was some "rogue" child process with pid 31969 which screwed up
>> the accounting of children and thus WaitPidDaemonThread is not aware that it
>> should call wait() to wait for pid 32094.
>> Apparently that rogue child process was not created via
>> PR_CreateProcess/_MD_CreateUnixProcess, otherwise it would be accounted for via
>> numProcs.
> 
> ktrace suggests that the child process is doing something unexpected (for me at
> least):
> NAMI  "/usr/local/lib/dri/r600_dri.so"
> NAMI  "/usr/local/lib/thunderbird/libdrm_radeon.so.1"
> NAMI  "/usr/local/lib/thunderbird/plugins/libdrm_radeon.so.1"
> NAMI  "/usr/local/lib/thunderbird/libdrm_radeon.so.1"
> NAMI  "/lib/libdrm_radeon.so.1"
> NAMI  "/usr/lib/libdrm_radeon.so.1"
> NAMI  "/usr/lib/compat/libdrm_radeon.so.1"
> NAMI  "/usr/local/lib/libdrm_radeon.so.1"
> NAMI  "/usr/local/lib/libdrm_radeon.so.1"
> NAMI  "/dev/dri"
> NAMI  "/dev/dri/card0"
> NAMI  "/dev/dri/card0"
> NAMI  "/dev/dri"
> NAMI  "/dev/dri/card0"
> NAMI  "/dev/dri/card0"
> 

OK, it seems that the culprit is mozilla/toolkit/xre/glxtest.cpp:
fire_glxtest_process() forks a new process, but doesn't wait(2) for it.
So when wait(2) is invoked later it may return a pid of this child before any
other child.
Not sure how to fix this or work around it.
Maybe by adding wait4(WNOHANG) loop to the _MD_InitProcesses code... not sure how
robust that would be.  Or maybe glxtest should use PR_CreateProcess instead of the
plain fork(2) that it uses now...
-- 
Andriy Gapon