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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-gecko To unsubscribe, send any mail to "[email protected]"
