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

[Andriy Gapon]

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