Closed Bug 496537 Opened 15 years ago Closed 15 years ago

Hang or deadlock while browsing new messages in IMAP folder (semaphore_wait_signal_trap), (Tb 2.0.0.22 with Enigmail plugin 0.96.0)

Categories

(MailNews Core :: Networking: IMAP, defect)

1.8 Branch
x86
macOS
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: astricker, Unassigned)

Details

(Keywords: hang, Whiteboard: [has protocol log])

Attachments

(3 files)

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_7; de-de) AppleWebKit/525.28.3 (KHTML, like Gecko) Version/3.2.3 Safari/525.28.3 Build Identifier: Thunderbird 2.0.0.21 (20090302) From time to times, usually right after startup, when I browse new mails, thunderbird locks complety up. (Looks like a deadlock for me). Reproducible: Always Steps to Reproduce: 1. Open Thunderbird 2. Read unread mail by using key "n" for next unread mail 3. repeat step 2. a few times in new folders (2-3x) Actual Results: Thunderbird hangs (going read in process manager). I waited 5-10min with no success. This happends only occasional, e.g. each 3th time. I've had this error about the 10th time now. The hangup is not reproducable with a single e-mail, the next time I'm usually able to open the same mail without any problem. On deadlock thunderbird does not use any CPU cycles. Expected Results: Should not hang... The only addition I've got installed is Enigmail 0.95.7. The last deadlock occured with a signed mail. I've got no idea about the other cases. If I analyse the process, I get this backtrace for the active thread: #0 0x964ef2ce in semaphore_wait_signal_trap () #1 0x965212c6 in _pthread_cond_wait () #2 0x96566539 in pthread_cond_wait () #3 0x00ef4a75 in PR_WaitCondVar () #4 0x00efc777 in _MD_WaitUnixProcess () #5 0x0155445e in nsPipeTransport::KillProcess () #6 0x01554e7a in nsPipeTransport::Finalize () #7 0x01554f3f in nsPipeTransport::Terminate () #8 0x0156068c in nsIPCService::ExecPipe () #9 0x00e628d1 in XPTC_InvokeByIndex () #10 0x004784bb in XPCWrappedNative::CallMethod () #11 0x00469813 in XPC_WN_CallMethod () #12 0x00d9bfaa in js_Invoke () #13 0x00d8e74b in js_Interpret () #14 0x00d9c818 in js_Invoke () #15 0x007645da in nsXPCWrappedJSClass::CheckForException () #16 0x007617d3 in nsXPCWrappedJS::SystemIsBeingShutDown () #17 0x00e6298a in XPTC_InvokeByIndex () #18 0x00e62d66 in nsXPTCStubBase::Stub16 () #19 0x00e628d1 in XPTC_InvokeByIndex () #20 0x004784bb in XPCWrappedNative::CallMethod () #21 0x00469813 in XPC_WN_CallMethod () #22 0x00d9bfaa in js_Invoke () #23 0x00d8e74b in js_Interpret () #24 0x00d9c818 in js_Invoke () #25 0x007645da in nsXPCWrappedJSClass::CheckForException () #26 0x007617d3 in nsXPCWrappedJS::SystemIsBeingShutDown () #27 0x00e6298a in XPTC_InvokeByIndex () #28 0x00e62adc in nsXPTCStubBase::Stub3 () #29 0x002ce619 in nsEventListenerManager::HandleEventSubType () #30 0x002cf710 in nsEventListenerManager::FixContextMenuEvent () #31 0x005b558c in nsGlobalWindow::HandleDOMEvent () #32 0x00290e52 in DocumentViewerImpl::DumpContentToPPM () #33 0x006cb7a2 in nsDocShell::EndPageLoad () #34 0x003474fd in nsWebShell::EndPageLoad () #35 0x006d244d in nsDocShell::CreateAboutBlankContentViewer () #36 0x00349623 in nsDocLoader::FireOnStateChange () #37 0x0034999d in nsDocLoader::doStopDocumentLoad () #38 0x00349a67 in nsDocLoader::DocLoaderIsEmpty () #39 0x00349d4b in nsDocLoader::doStartDocumentLoad () #40 0x00415850 in nsLoadGroup::~nsLoadGroup () #41 0x002538ca in PresShell::RemoveDummyLayoutRequest () #42 0x00253922 in PresShell::RemoveDummyLayoutRequest () #43 0x00e4c529 in PL_HandleEvent () #44 0x00e4c7e2 in PL_ProcessPendingEvents () #45 0x905ba595 in CFRunLoopRunSpecific () #46 0x905bac78 in CFRunLoopRunInMode () #47 0x93e9928c in RunCurrentEventLoopInMode () #48 0x93e990a5 in ReceiveNextEventCommon () #49 0x93ef7b36 in _AcquireNextEvent () #50 0x93ef6293 in RunApplicationEventLoop () #51 0x0036f68b in nsAppShell::~nsAppShell () #52 0x003d9a6e in nsAppStartup::DestroyExitEvent () #53 0x00005e66 in XRE_main () #54 0x00002a70 in main ()
Can you try running Thunderbird in -safe-mode for a while and see what's going on ? Could you try to reproduce and get the imap logs (see https://wiki.mozilla.org/MailNews:Logging for instructions). Also the code for imap handling has been greatly henhanced since 2.x in thunderbird3.0b2 - could try to run that version and tell us if things are better ?
Component: General → Networking: IMAP
Product: Thunderbird → MailNews Core
QA Contact: general → networking.imap
Version: unspecified → 1.8 Branch
Thunderbird is now running with logging enabled for more than a week. It didn't hang since. I'll try for another week.
The attached log are the last part of the imap.log (~169MB) starting with the last message displayed before Thunderbird locked up.
I forced the Thunderbird process to quit, this is the OSX process analyse output afterwards. This matches the same moment as the imap.log attached.
After normal completion of full mail download of simplest text/plain mail, > 11 UID fetch 1628 (UID RFC822.SIZE BODY[]) >(snip) > 11 OK Fetch completed. next flow happens. > SendData: 12 IDLE > CONTROL: PSEUDO-Interrupted > SendData: DONE > + idling > * OK Still here > * OK Still here > * OK Still here > * OK Still here What is "CONTROL: PSEUDO-Interrupted"? Why "SendData: DONE" before "+idling" from server? What is "* OK Still here" from server after "+idling" response?
Andreas do you have acces to your imap server's log by any chance ? Anything interesting in these with regards to Wada's questions in comment 5 ?
Thanks to our great administrator, I've got the log file from our dovecot IMAP server. btw. the Thunderbird version in question is 2.0.0.22 (20090605) with installed Enigmail plugin 0.96.0 (20090717-0949).
Andreas, do you see this issue with newer thunderbird and enigmail?
Severity: normal → critical
Keywords: hang
Whiteboard: [has protocol log]
I'm now working with 3.0.x a few months and it never happened again. The IMAP access even feels faster. I close the ticket. Thanks for you help. I really like Thunderbird :-)
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
FIXED=="resolved by known patch at B.M.O". Closing as WORKSFORME(fixed by unknown patch at B.M.O), and adding "Enigmail plugin 0.96.0" for ease of search.
Resolution: FIXED → WORKSFORME
Summary: Hang or deadlock while browsing new messages in IMAP folder (semaphore_wait_signal_trap) → Hang or deadlock while browsing new messages in IMAP folder (semaphore_wait_signal_trap), (Tb 2.0.0.22 with Enigmail plugin 0.96.0)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: