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)
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.
Comment 1•7 years ago
|
||
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
Comment 2•7 years ago
|
||
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.
Comment 5•7 years ago
|
||
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.
Updated•6 years ago
|
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.
Description
•