Closed Bug 1410286 Opened 7 years ago Closed 7 years ago

Crash in shutdownhang | _PR_MD_WAIT_CV | _PR_WaitCondVar | NS_InvokeByIndex caused by gpg.exe not shut down

Categories

(Thunderbird :: General, defect)

52 Branch
x86
Windows XP
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: luweitest, Unassigned)

References

Details

(Keywords: crash)

Crash Data

This bug was filed from the Socorro interface and is 
report bp-c0a20571-e363-4415-8c88-dde480171020.
=============================================================
This is a new crash since I last removed all pending crash reports, and I think similar crash that I submitted before have the same cause: it's related to Enigmail extension, or GnuPG, or TB's handling of it. A series of gpg.exe is left in process list and seems dead; It happens when a composing window is opening, and at that time sending mail button becomes slow responding; 

I am not encrypting or decrypting anything, yet Enigmails console show like:

enigmail> "C:\Program Files\GnuPG\bin\gpg.exe" --charset utf-8 --display-charset utf-8 --use-agent --batch --no-tty --status-fd 2 --with-fingerprint --fixed-list-mode --with-colons --list-secret-keys
gpg: waiting for lock E:/key/gnupg_spawn_agent_sentinel.lock...
gpg: waiting for lock E:/key/gnupg_spawn_agent_sentinel.lock...
gpg: waiting for lock E:/key/gnupg_spawn_agent_sentinel.lock...
gpg: waiting for lock E:/key/gnupg_spawn_agent_sentinel.lock...
gpg: waiting for lock E:/key/gnupg_spawn_agent_sentinel.lock...
gpg: waiting for lock E:/key/gnupg_spawn_agent_sentinel.lock...
gpg: can't connect to the agent: End of file
enigmail> "C:\Program Files\GnuPG\bin\gpg.exe" --charset utf-8 --display-charset utf-8 --use-agent --batch --no-tty --status-fd 2 --fixed-list-mode --with-colons --list-config

gpg: waiting for lock E:/key/gnupg_spawn_agent_sentinel.lock...
gpg: waiting for lock E:/key/gnupg_spawn_agent_sentinel.lock...
gpg: waiting for lock E:/key/gnupg_spawn_agent_sentinel.lock...
gpg: waiting for lock E:/key/gnupg_spawn_agent_sentinel.lock...
gpg: can't connect to the agent: End of file
gpg: can't connect to the agent: End of file
gpg: waiting for lock E:/key/gnupg_spawn_agent_sentinel.lock...
gpg: waiting for lock E:/key/gnupg_spawn_agent_sentinel.lock...
gpg: waiting for lock E:/key/gnupg_spawn_agent_sentinel.lock...
gpg: waiting for lock E:/key/gnupg_spawn_agent_sentinel.lock...
gpg: waiting for lock E:/key/gnupg_spawn_agent_sentinel.lock...
gpg: can't connect to the agent: End of file
gpg: waiting for lock E:/key/gnupg_spawn_agent_sentinel.lock...
gpg: waiting for lock E:/key/gnupg_spawn_agent_sentinel.lock...
gpg: waiting for lock E:/key/gnupg_spawn_agent_sentinel.lock...
gpg: can't connect to the agent: End of file

killing the gpg-agent.exe will get it restart, and zombie gpg.exe disappear.
Stack, FWIW
bp-c0a20571-e363-4415-8c88-dde480171020
0	ntdll.dll	KiFastSystemCallRet	
1	ntdll.dll	ZwWaitForSingleObject	
2	kernel32.dll	WaitForSingleObjectEx	
3	kernel32.dll	WaitForSingleObject	
4	nss3.dll	_PR_MD_WAIT_CV	nsprpub/pr/src/md/windows/w95cv.c:248
5	nss3.dll	_PR_WaitCondVar	nsprpub/pr/src/threads/combined/prucv.c:172
6	nss3.dll	PR_WaitCondVar	nsprpub/pr/src/threads/combined/prucv.c:525
7	xul.dll	mozilla::CondVar::Wait(unsigned int)	C:/builds/moz2_slave/tb-rel-c-esr52-w32_bld-0000000/build/objdir-tb/dist/include/mozilla/CondVar.h:79
8	xul.dll	nsEventQueue::GetEvent(bool, nsIRunnable**, mozilla::BaseAutoLock<mozilla::Mutex>&)	xpcom/threads/nsEventQueue.cpp:57
9	xul.dll	nsThread::nsChainedEventQueue::GetEvent(bool, nsIRunnable**, mozilla::BaseAutoLock<mozilla::Mutex>&)	xpcom/threads/nsThread.cpp:788
10	xul.dll	nsThread::GetEvent(bool, nsIRunnable**, mozilla::BaseAutoLock<mozilla::Mutex>&)	xpcom/threads/nsThread.cpp:1147
Component: Untriaged → General
Keywords: crash
It's no surprise that TB crashes when the are still running instances of gpg.

There's nothing wrong with Enigmail here, gpg does not terminate because it waits for a lock created by another instance of gpg.

Lu, you have to make sure that there are no more gpg processes, and then delete any lock files in your GNUPGHOME directory. The file(s) may be hidden. The directory usually under %appdata%\Gnupg
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
(In reply to Patrick Brunschwig from comment #2)
> It's no surprise that TB crashes when the are still running instances of gpg.
> 
> There's nothing wrong with Enigmail here, gpg does not terminate because it
> waits for a lock created by another instance of gpg.
> 
> Lu, you have to make sure that there are no more gpg processes, and then
> delete any lock files in your GNUPGHOME directory. The file(s) may be
> hidden. The directory usually under %appdata%\Gnupg

All hanging gpg.exe processes were started by TB (I use procexp tree view). Maybe it's caused by another dead gpg process long ago. Now I deleted all the size 0 files including lock files, and I'll see if it will happen again. 

Till now I observed this: gpg-agent.exe will not close with TB (maybe it is designed, because it will not close with gpg.exe run in cmd either), and the lock files, namely gpg-v21-migrated, gnupg_spawn_agent_sentinel.lock, gpg-v21-migrated.lock, once created, will remain there, not get deleted automatically. There seems to have 4 zero-size files at first, but I shift-deleted them too quickly and cannot recall what another file was.
I find that, if gpg-agent.exe is started by a command line gpg.exe, and remains after gpg.exe exits (it always remains), then later Enigmail's calling of gpg.exe may get stuck (gpg.exe dead in the process list, message cannot send). But it can succeed with more possibility; I still cannot find a 100% reproducible pattern. Whether gpg-agent.exe started by Enigmail will cause such bug I am still not sure and will keep an eye. As for those lock files, they are always recreated after calling gpg-agent.exe and never got deleted automatically, though their existence seems have nothing to do with the bug.
Believe it or not, as long as gpg reports the following, it will not do anything else than wait for the lock to be released.

gpg: waiting for lock E:/key/gnupg_spawn_agent_sentinel.lock...

Gpg will also not terminate in this state. If you try to shutdown Thunderbird in this situation, it *will* crash because it's still waiting for output from the waiting gpg process. I cannot tell you why there are these lock files, they are created by gpg for internal reasons.

If you want to known more, you best ask the GnuPG mailing list or create a ticket with GnuPG. The source cause of your problem is not in Thunderbird nor in Enigmail.
(In reply to Patrick Brunschwig from comment #5)
> ...
> If you want to known more, you best ask the GnuPG mailing list or create a
> ticket with GnuPG. The source cause of your problem is not in Thunderbird
> nor in Enigmail.

Thanks for the clarification. Not ready to step into another community yet :) Anyway we do these things in spare time, I could just kill gpg-agent if urgent. Thanks for your efforts too.
See Also: → 1358564
See Also: → 1307965
See Also: → 1307963
Resolution: WONTFIX → INVALID
Summary: Crash in shutdownhang | _PR_MD_WAIT_CV | _PR_WaitCondVar | NS_InvokeByIndex → Crash in shutdownhang | _PR_MD_WAIT_CV | _PR_WaitCondVar | NS_InvokeByIndex caused by gpg.exe not shut down
You need to log in before you can comment on or make changes to this bug.