This bug was filed from the Socorro interface and is report bp-b61f559a-11da-484d-b28e-5509f2120730 . ============================================================= Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Firefox/17.0 SeaMonkey/2.14a1 ID:20120729003004 c-c: a3b46de2b086 m-c: 29bff59d3bbe crash during restart using the Restartless Restart extension. I had: - accepted the "Close all mailnews tabs?" popup - accepted the "Browser will attempt to restore all your tabs" popup ChatZilla had closed before the rest All the above is expected; then the crash happened. Related with bug 777063? (crash at nsChromeTreeOwner::SetTitle immediately after sending mail, while destroying the mail-compose window) This is currently the 3rd ("bronze") top crasher for SeaMonkey 2.14a1 this week, with 8 crashes under Windows; bug 777063 has both "gold" and "silver". For Thunderbird 17.0a1, Socorro mentions bug 777063 for all three top crashing signatures and this one comes immediately after (with 125 Windows crashes this week). Searching the topcrasher page for Firefox 17.0a1 for "nsChr" gives a null result. Here comes the crash report: Signature nsChromeTreeOwner::Destroy UUID b61f559a-11da-484d-b28e-5509f2120730 Date Processed 2012-07-30 06:57:46 Uptime 55158 Last Crash 20.9 hours before submission Install Age 15.3 hours since version was first installed. Install Time 2012-07-29 15:36:09 Product SeaMonkey Version 2.14a1 Build ID 20120729003004 Release Channel nightly OS Linux OS Version 0.0.0 Linux 3.1.10-1.16-desktop #1 SMP PREEMPT Wed Jun 27 05:21:40 UTC 2012 (d016078) x86_64 Build Architecture amd64 Build Architecture Info family 15 model 4 stepping 1 Crash Reason SIGSEGV Crash Address 0x0 User Comments during restart, after accepting "close all mail tabs" and "browser will attempt to restore all your tabs". App Notes GLXtest process failed (exited with status 1): X error occurred in GLX probe, error_code=9, request_code=55, minor_code=0 WebGL? WebGL- Processor Notes EMCheckCompatibility False Winsock LSP Adapter Vendor ID Adapter Device ID Bugzilla - Report this bug in SeaMonkey, Core, Plug-Ins, or Toolkit Crashing Thread Frame Module Signature Source 0 libxul.so nsChromeTreeOwner::Destroy xpfe/appshell/src/nsChromeTreeOwner.cpp:350 1 libxul.so nsMsgComposeService::CloseHiddenCachedWindow mailnews/compose/src/nsMsgComposeService.cpp:319 2 libxul.so nsMsgComposeService::DeleteCachedWindows mailnews/compose/src/nsMsgComposeService.cpp:208 3 libxul.so nsMsgComposeService::Observe mailnews/compose/src/nsMsgComposeService.cpp:332 4 libxul.so nsObserverList::NotifyObservers xpcom/ds/nsObserverList.cpp:99 5 libxul.so nsObserverService::NotifyObservers xpcom/ds/nsObserverService.cpp:149 6 libxul.so nsAppStartup::Quit toolkit/components/startup/nsAppStartup.cpp:495 7 libxul.so nsAppStartup::ExitLastWindowClosingSurvivalArea toolkit/components/startup/nsAppStartup.cpp:565 8 libxul.so nsAppStartup::Observe toolkit/components/startup/nsAppStartup.cpp:723 9 libxul.so nsObserverList::NotifyObservers xpcom/ds/nsObserverList.cpp:99 10 libxul.so nsObserverService::NotifyObservers xpcom/ds/nsObserverService.cpp:149 11 libxul.so nsXULWindow::Destroy xpfe/appshell/src/nsXULWindow.cpp:527 12 libxul.so nsWebShellWindow::Destroy xpfe/appshell/src/nsWebShellWindow.cpp:788 13 libxul.so nsGlobalWindow::ReallyCloseWindow dom/base/nsGlobalWindow.cpp:6636 14 libxul.so nsCloseEvent::Run dom/base/nsGlobalWindow.cpp:6421 15 libxul.so nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:624 16 libxul.so NS_ProcessNextEvent_P objdir/mozilla/xpcom/build/nsThreadUtils.cpp:220 17 libxul.so mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:82 18 libxul.so MessageLoop::Run ipc/chromium/src/base/message_loop.cc:201 19 libxul.so nsBaseAppShell::Run widget/xpwidgets/nsBaseAppShell.cpp:163 20 libxul.so nsAppStartup::Run toolkit/components/startup/nsAppStartup.cpp:271 21 libxul.so XREMain::XRE_mainRun toolkit/xre/nsAppRunner.cpp:3798 22 libxul.so XREMain::XRE_main toolkit/xre/nsAppRunner.cpp:3875 23 libxul.so XRE_main toolkit/xre/nsAppRunner.cpp:3951 24 seamonkey main suite/app/nsSuiteApp.cpp:173 25 libc-2.14.1.so libc-2.14.1.so@0x2123c 26 seamonkey nsGetterAddRefs<nsIFile>::operator nsIFile**
7 years ago
Summary: crash in nsChromeTreeOwner::Destroy → crash in nsChromeTreeOwner::Destroy during restart
https://crash-stats.mozilla.com/report/list?signature=nsChromeTreeOwner%3A%3ADestroy%28%29 says that the Windows variant of this signature mostly happens on Thunderbird and SeaMonkey, crashing there in Firefox is rare. Also, crashes within a minuter from startup are rare, most are in longer running sessions. And all those crashes are only in current Nightly versions. The Linux signature in https://crash-stats.mozilla.com/report/list?signature=nsChromeTreeOwner%3A%3ADestroy gives a similar picture. That means the cause of the crash you are seeing could very well be the general problem seems in those other crashes with that signature as well. I'm adding the Windows signature variant to this bug.
Crash Signature: [@ nsChromeTreeOwner::Destroy] → [@ nsChromeTreeOwner::Destroy] [@ nsChromeTreeOwner::Destroy()]
Items 1 and 2 on the stack (immediately below the "signature") make me believe that this is a MailNews crash, possibly closely related to bug 777063. I'm moving this to MailNews Core for the time being (the Socorro crash dump page has bug-creation links for only "SeaMonkey" "Core" "Plug-ins" and "Toolkit").
Component: General → Composition
Product: SeaMonkey → MailNews Core
P.S. There are five "user comments" on all these crashes, and they all point to a crash at closedown, or during restart, or when applying an update.
7 years ago
Summary: crash in nsChromeTreeOwner::Destroy during restart → crash in nsChromeTreeOwner::Destroy at closedown
(In reply to Robert Kaiser (:firstname.lastname@example.org) from comment #1) > That means the cause of the crash you are seeing could very well be the > general problem seems in those other crashes with that signature as well. i think so. crashes for this started with 20120724030551 build. I'm not giving time to dig through bug 777063 to see if the start dates match precisely (I wish we had a standard in place to notate this in bz to save time).
Depends on: 777063
As a number of the bug 777063 signatures are nsChromeTreeOwner::* as well, it might as well be a dupe. Tony, if you set mail.compose.max_recycled_windows to 0, do those crashes go away?
(In reply to Robert Kaiser (:email@example.com) from comment #5) > As a number of the bug 777063 signatures are nsChromeTreeOwner::* as well, > it might as well be a dupe. > > Tony, if you set mail.compose.max_recycled_windows to 0, do those crashes go > away? I'll set this pref now. But I don't get these crashes every time; it may take a few days before I'm confident that they're gone.
(In reply to Tony Mechelynck [:tonymec] from comment #6) > I'll set this pref now. But I don't get these crashes every time; it may > take a few days before I'm confident that they're gone. Sure, no problem. In any case, if this pref change makes them go away, we know it's a dupe of bug 777063, i.e. it's caused by the compose window recycling.
I've reset mail.compose.max_recycled_windows to its default of 1 after bug 777063 was FIXED and still no crash — no crash when sending mail (a few times per day, bug 777063) and no crash at closedown (about once per 24h, this bug).
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 777063
You need to log in before you can comment on or make changes to this bug.