Closed Bug 366220 Opened 19 years ago Closed 16 years ago

seamonkey freeze probably caused by enigmail

Categories

(SeaMonkey :: MailNews: Message Display, defect)

Product:
SeaMonkey
Component:
MailNews: Message Display
Version:
1.8 Branch
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: wolfiR, Unassigned)

Details

(Keywords: hang)

I run 1.8 branch builds of seamonkey for some months now together with enigmail 0.94.1 and I run into seamonkey freezes almost once a day. The backtraces always look the same like this: (gdb) bt #0 0xffffe405 in __kernel_vsyscall () #1 0xf7ce9556 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xf7d18f91 in PR_WaitCondVar () from /usr/lib/libnspr4.so #3 0xf7d21039 in PR_Now () from /usr/lib/libnspr4.so #4 0xf7d0fb44 in PR_WaitProcess () from /usr/lib/libnspr4.so #5 0xf17a9735 in NSGetModule () from /usr/lib/seamonkey/components/libenigmime.so #6 0xf17a988e in NSGetModule () from /usr/lib/seamonkey/components/libenigmime.so #7 0xf7ebcb19 in XPTC_InvokeByIndex () from /usr/lib/seamonkey/libxpcom_core.so #8 0xf6fd97a4 in NSGetModule () from /usr/lib/seamonkey/components/libxpconnect.so #9 0xf6fdf86f in NSGetModule () from /usr/lib/seamonkey/components/libxpconnect.so #10 0xf7dbc269 in js_Invoke () from /usr/lib/seamonkey/libmozjs.so #11 0xf7dacd56 in js_Interpret () from /usr/lib/seamonkey/libmozjs.so #12 0xf7dbc71f in js_Invoke () from /usr/lib/seamonkey/libmozjs.so #13 0xf6fd73da in NSGetModule () from /usr/lib/seamonkey/components/libxpconnect.so #14 0xf6fd1033 in NSGetModule () from /usr/lib/seamonkey/components/libxpconnect.so #15 0xf7ebd6e1 in xptc_dummy () from /usr/lib/seamonkey/libxpcom_core.so #16 0xf17a48ff in NSGetModule () from /usr/lib/seamonkey/components/libenigmime.so #17 0xf17a4c6b in NSGetModule () from /usr/lib/seamonkey/components/libenigmime.so #18 0xf17b4378 in NSGetModule () from /usr/lib/seamonkey/components/libenigmime.so #19 0xf17a08bb in NSGetModule () from /usr/lib/seamonkey/components/libenigmime.so #20 0xf17b4378 in NSGetModule () from /usr/lib/seamonkey/components/libenigmime.so #21 0xf17b4334 in NSGetModule () from /usr/lib/seamonkey/components/libenigmime.so #22 0xf17a08bb in NSGetModule () from /usr/lib/seamonkey/components/libenigmime.so #23 0xf4503ee9 in NSGetModule () from /usr/lib/seamonkey/components/libmsgimap.so #24 0xf6ed1166 in NSGetModule () from /usr/lib/seamonkey/components/libnecko.so #25 0xf6ed149b in NSGetModule () from /usr/lib/seamonkey/components/libnecko.so #26 0xf7e84cb2 in nsInputStreamReadyEvent::EventHandler () from /usr/lib/seamonkey/libxpcom_core.so #27 0xf7ea2517 in PL_HandleEvent () from /usr/lib/seamonkey/libxpcom_core.so #28 0xf7ea282b in PL_ProcessPendingEvents () from /usr/lib/seamonkey/libxpcom_core.so #29 0xf7ea48ae in nsEventQueueImpl::~nsEventQueueImpl () from /usr/lib/seamonkey/libxpcom_core.so #30 0xf5fc0a15 in __cxa_pure_virtual () from /usr/lib/seamonkey/components/libwidget_gtk2.so #31 0x080e9208 in ?? () #32 0x083337b0 in ?? () #33 0xffe19be8 in ?? () #34 0xf77bc66d in g_io_channel_unix_get_fd () from /opt/gnome/lib/libglib-2.0.so.0 #35 0xf77bc66d in g_io_channel_unix_get_fd () from /opt/gnome/lib/libglib-2.0.so.0 #36 0xf7792de2 in g_main_context_dispatch () from /opt/gnome/lib/libglib-2.0.so.0 #37 0xf7795e1f in g_main_context_prepare () from /opt/gnome/lib/libglib-2.0.so.0 #38 0xf77961c9 in g_main_loop_run () from /opt/gnome/lib/libglib-2.0.so.0 #39 0xf7ac3cd4 in gtk_main () from /opt/gnome/lib/libgtk-x11-2.0.so.0 #40 0xf5fc0e82 in __cxa_pure_virtual () from /usr/lib/seamonkey/components/libwidget_gtk2.so #41 0x081f3cf8 in ?? () This looks like that it's triggered by enigmail but I'm not sure. It happens when I switch from one mail to another (on an IMAP server which might be interesting when it might be related to timing issues) but only once a day in average, while I'm working the whole day with mailnews and a lot of mails. That's not easy to reproduce. I've tried by clicking fast through my mails but failed. So it might be hard to find. But to let SM people know that I see this and maybe someone has any idea about it I file it here.
Is the stack trace from a build without symbols...?
Unfortunately yes. I run optimized builds usually ;-) I'll try to get a trace with debuginfo at some point.
If you do, be sure to do |call DumpJSStack()| in gdb to see what JS is doing too.
Assignee: general → mail
Component: General → MailNews: Main Mail Window
QA Contact: general
call DumpJSStack() doesn't work but here is a backtrace with debugging symbols (not for NSPR though) #0 0xffffe405 in __kernel_vsyscall () #1 0xf7d9f556 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xf7dcef91 in PR_WaitCondVar () from /usr/lib/libnspr4.so #3 0xf7dd7039 in PR_Now () from /usr/lib/libnspr4.so #4 0xf7dc5b44 in PR_WaitProcess () from /usr/lib/libnspr4.so #5 0xf3072735 in nsPipeTransport::KillProcess (this=0xc0ac2b8) at nsPipeTransport.cpp:614 #6 0xf307288e in nsPipeTransport::ExitCode (this=0xb5ec828, _retval=0xffa5a568) at nsPipeTransport.cpp:732 #7 0xf7f71b19 in XPTC_InvokeByIndex () from /usr/lib/seamonkey/libxpcom_core.so #8 0xf708f7c4 in XPCWrappedNative::CallMethod (ccx=@0xffa5a698, mode=XPCWrappedNative::CALL_METHOD) at xpcwrappednative.cpp:2169 #9 0xf709588f in XPC_WN_CallMethod (cx=0xa58d160, obj=0xa2ab2a0, argc=0, argv=0xcba7688, vp=0xffa5a7b4) at xpcwrappednativejsops.cpp:1455 #10 0xf7e61a2f in js_Invoke (cx=0xa58d160, argc=0, flags=0) at jsinterp.c:1396 #11 0xf7e63847 in js_Interpret (cx=0xa58d160, pc=0x944f9fd ":", result=0xffa5ab14) at jsinterp.c:3959 #12 0xf7e61eee in js_Invoke (cx=0xa58d160, argc=10, flags=2) at jsinterp.c:1415 #13 0xf708c3e0 in nsXPCWrappedJSClass::CallMethod (this=0x942ed38, wrapper=0x9430578, methodIndex=33, info=0x8b39a78, nativeParams=0xffa5ae08) at xpcwrappedjsclass.cpp:1415 #14 0xf7087063 in nsXPCWrappedJS::CallMethod (this=0x9430578, methodIndex=65532, info=0x8b39a78, params=0xffa5ae08) at xpcwrappedjs.cpp:467 #15 0xf7f726e1 in PrepareAndDispatch (methodIndex=<value optimized out>, self=0x9430578, args=<value optimized out>) at xptcstubs_gcc_x86_unix.cpp:100 #16 0xf7f71b19 in XPTC_InvokeByIndex () from /usr/lib/seamonkey/libxpcom_core.so #17 0xf708f7c4 in XPCWrappedNative::CallMethod (ccx=@0xffa5b19c, mode=XPCWrappedNative::CALL_METHOD) at xpcwrappednative.cpp:2169 #18 0xf709588f in XPC_WN_CallMethod (cx=0xa58d160, obj=0xa2ab958, argc=10, argv=0xcba7398, vp=0xffa5b2b8) at xpcwrappednativejsops.cpp:1455 #19 0xf7e61a2f in js_Invoke (cx=0xa58d160, argc=10, flags=0) at jsinterp.c:1396 #20 0xf7e63847 in js_Interpret (cx=0xa58d160, pc=0x8b7891d ":", result=0xffa5b618) at jsinterp.c:3959 #21 0xf7e61eee in js_Invoke (cx=0xa58d160, argc=1, flags=2) at jsinterp.c:1415 #22 0xf708d3fa in nsXPCWrappedJSClass::CallMethod (this=0x84baee0, wrapper=0xbc96c30, methodIndex=3, info=0x82d8040, nativeParams=0xffa5b90c) at xpcwrappedjsclass.cpp:1415 #23 0xf7087063 in nsXPCWrappedJS::CallMethod (this=0xbc96c30, methodIndex=65532, info=0x82d8040, params=0xffa5b90c) at xpcwrappedjs.cpp:467 #24 0xf7f726e1 in PrepareAndDispatch (methodIndex=<value optimized out>, self=0xbc96c30, args=<value optimized out>) at xptcstubs_gcc_x86_unix.cpp:100 #25 0xf644d290 in nsEventListenerManager::HandleEventSubType (this=0xab6eea8, aListenerStruct=0xab6ef40, aListener=0xbc96c30, aDOMEvent=0xaefc9e8, aCurrentTarget=0xbc13bac, aSubType=1, aPhaseFlags=7) at nsEventListenerManager.cpp:1655 #26 0xf644ef50 in nsEventListenerManager::HandleEvent (this=0xab6eea8, aPresContext=0xa540340, aEvent=0xffa5bc1c, aDOMEvent=0xffa5bbd8, aCurrentTarget=0xbc13bac, aFlags=7, aEventStatus=0xffa5bc44) at nsEventListenerManager.cpp:1759 #27 0xf6569f37 in nsGlobalWindow::HandleDOMEvent (this=0xb230e30, aPresContext=0xa540340, aEvent=0xffa5bc1c, aDOMEvent=0xffa5bbd8, aFlags=7, aEventStatus=0xffa5bc44) at nsGlobalWindow.cpp:1685 #28 0xf624e750 in DocumentViewerImpl::LoadComplete (this=0xb57d888, aStatus=0) at nsDocumentViewer.cpp:1013 #29 0xf5d8a922 in nsDocShell::EndPageLoad (this=0xa4d1d08, aProgress=0xa4d1d1c, aChannel=0xb5fd8f8, aStatus=0) at nsDocShell.cpp:4794 #30 0xf5d92649 in nsWebShell::EndPageLoad (this=0xa4d1d08, aProgress=0xa4d1d1c, channel=0xb5fd8f8, aStatus=0) at nsWebShell.cpp:661 #31 0xf5d8ace6 in nsDocShell::OnStateChange (this=0xa4d1d08, aProgress=0xa4d1d1c, aRequest=0xb5fd8f8, aStateFlags=131088, aStatus=0) at nsDocShell.cpp:4709 #32 0xf5d9d9d5 in nsDocLoader::FireOnStateChange (this=0xa4d1d08, aProgress=0xa4d1d1c, aRequest=0xb5fd8f8, aStateFlags=131088, aStatus=0) at nsDocLoader.cpp:1210 #33 0xf5d9dde5 in nsDocLoader::doStopDocumentLoad (this=0xa4d1d08, request=0xb5fd8f8, aStatus=0) at nsDocLoader.cpp:833 #34 0xf5d9deda in nsDocLoader::DocLoaderIsEmpty (this=0xa4d1d08) at nsDocLoader.cpp:739 #35 0xf5d9e266 in nsDocLoader::OnStopRequest (this=0xa4d1d08, aRequest=0x9c4ef20, aCtxt=0x0, aStatus=0) at nsDocLoader.cpp:662 #36 0xf6f8c711 in nsLoadGroup::RemoveRequest (this=0xbe3c4b0, request=0x9c4ef20, ctxt=0x0, aStatus=0) at nsLoadGroup.cpp:732 #37 0xf626924b in PresShell::RemoveDummyLayoutRequest (this=0xa2ff180) at nsPresShell.cpp:7171 #38 0xf62692b8 in HandleDummyLayoutRequestPLEvent (aEvent=0xc5c2718) at nsPresShell.cpp:7070 #39 0xf7f57517 in PL_HandleEvent (self=0xc5c2718) at plevent.c:688 #40 0xf7f5782b in PL_ProcessPendingEvents (self=0x80f4be0) at plevent.c:623 #41 0xf7f598ae in nsEventQueueImpl::ProcessPendingEvents (this=0x80eaab0) at nsEventQueue.cpp:417 #42 0xf6076a15 in event_processor_callback (source=0x8365ae8, condition=G_IO_IN, data=0x1) at nsAppShell.cpp:67 #43 0xf787266d in g_io_channel_unix_get_fd () from /opt/gnome/lib/libglib-2.0.so.0 #44 0xf7848de2 in g_main_context_dispatch () from /opt/gnome/lib/libglib-2.0.so.0 #45 0xf784be1f in g_main_context_prepare () from /opt/gnome/lib/libglib-2.0.so.0 #46 0xf784c1c9 in g_main_loop_run () from /opt/gnome/lib/libglib-2.0.so.0 #47 0xf7b79cd4 in gtk_main () from /opt/gnome/lib/libgtk-x11-2.0.so.0 #48 0xf6076e82 in nsAppShell::Run (this=0x81f5408) at nsAppShell.cpp:139 #49 0xf60f2254 in nsAppStartup::Run (this=0x81f3f78) at nsAppStartup.cpp:207 #50 0x0804e0c1 in main1 (argc=1, argv=0xffa5c9a4, nativeApp=<value optimized out>) at nsAppRunner.cpp:1255 #51 0x0804bb96 in main (argc=Cannot access memory at address 0x0 ) at nsAppRunner.cpp:1756 #52 0xf73a3f9c in __libc_start_main () from /lib/libc.so.6 #53 0x0804abe1 in _start ()
According to https://bugzilla.novell.com/show_bug.cgi?id=195572 this also happens with Thunderbird.
Could you send me an example email that triggers this freeze?
The problem is that it's not reproducable: - it happens while opening a certain mail - I kill seamonkey and reopen it - I open the same mail and it works in 99,9% of the cases So far I have no idea how to trigger it but it happens to me with recent SM and enigmail versions again at least once or twice a day while browsing through my mailbox. I only happens with signed (and maybe encoded) mails where enigmail is invoked for real.
Do you see a running gpg process while SM is blocking? If so, does killing gpg unfreeze SM?
In contrary to the references Novell bug I don't see a gpg process while I can't be sure if there is a gpg process still up at the moment when SM freezes and terminates soon after.
SeaMonkey v1.0.x is not supported anymore. Can you reproduce with SeaMonkey v1.1.9 ?
Keywords: hang
Unfortunately I'm not using SeaMonkey myself anymore so I haven't seen it again. Using Thunderbird 2.0.0.x with Enigmail doesn't expose the issue (but probably never had).
Wolfgang, thanks for the update. I suppose then we close this incomplete
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.