Date: Fri, 19 Aug 2011 18:48:39 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Alex Dupre <ale@FreeBSD.org> Cc: gecko@FreeBSD.org, Doug Barton <dougb@FreeBSD.org> Subject: Re: cvs commit: ports UPDATING ports/mail/enigmail Makefile distinfo pkg-message ports/mail/enigmail-thunderbird Makefile Message-ID: <4E4E85D7.4070709@FreeBSD.org> In-Reply-To: <4E4E82C6.9040606@FreeBSD.org> References: <201108181007.p7IA7PgK032094@repoman.freebsd.org> <4E4D6AD3.2050708@FreeBSD.org> <4E4D70FF.2060206@FreeBSD.org> <4E4DCFED.4070601@FreeBSD.org> <4E4E05BA.9070707@FreeBSD.org> <4E4E7A69.8050406@FreeBSD.org> <4E4E7D5D.4050204@FreeBSD.org> <4E4E812B.6000007@FreeBSD.org> <4E4E82C6.9040606@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E4E85D7.4070709>