on 19/08/2011 18:12 Andriy Gapon said the following: > on 19/08/2011 17:59 Andriy Gapon said the following: >> nsIPCService::RunPipe -> nsPipeTransport::Terminate -> nsPipeTransport::Kill >> -> >> IPC_WaitProcess == _MD_WaitUnixProcess > > BTW, curiously enough this how IPC_WaitProcess invocation looks in > nsPipeTransport::Kill: > > // Reap process (to avoid memory leaks in NSPR) > // **NOTE** This could cause this (UI?) thread to hang > status = IPC_WaitProcess(mProcess, &mExitCode);
I added some more printfs and here is very interesting stuff: _MD_InitProcesses! PR_CreateThread(WaitPidDaemonThread) ForkAndExec, path = /usr/local/bin/gpg2 ForkAndExec, pid = 32094 ForkAndExec: numProcs 0 -> 1 waiting for children ProcessReapedChildInternal, pid = 31969 ProcessReapedChildInternal: FindPidTable returned NULL no children before inputStream->Close() before pipeTrans->Terminate() before IPC_WaitProcess _MD_WaitUnixProcess, pid = 32094 _MD_WaitUnixProcess: FindPidTable returned NULL 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. Hmm... -- Andriy Gapon _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-gecko To unsubscribe, send any mail to "[email protected]"
