From owner-freebsd-gecko@FreeBSD.ORG Fri Aug 19 15:48:42 2011 Return-Path: Delivered-To: gecko@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 789971065674; Fri, 19 Aug 2011 15:48:42 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 667568FC14; Fri, 19 Aug 2011 15:48:41 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA01878; Fri, 19 Aug 2011 18:48:39 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E4E85D7.4070709@FreeBSD.org> Date: Fri, 19 Aug 2011 18:48:39 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: Alex Dupre 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> In-Reply-To: <4E4E82C6.9040606@FreeBSD.org> X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: gecko@FreeBSD.org, Doug Barton Subject: Re: cvs commit: ports UPDATING ports/mail/enigmail Makefile distinfo pkg-message ports/mail/enigmail-thunderbird Makefile X-BeenThere: freebsd-gecko@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Gecko Rendering Engine issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 15:48:42 -0000 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