Trunk builds of Seamonkey, Firefox (Minefield) and Thunderbird from 2007-04-10 OS: Debian GNU/Linux 4.0 Happens: Sometimes Steps to reproduce: 1. Start the application with the "-P" switch. (for Seamonkey) Click "Manage Profiles..." 2. Click "Create Profile" Actual results: Crash (sometimes). Desired results: Profile creation dialog. The long story: First I'd got the Seamonkey trunk, and started it with my default profile accidentally, and pressed Ctrl-C by noticing it. On next start, Talkback came up; I didn't notice that I had pressed the Create profile button already; the result was TB31052677K. One more start (careful), and there is TB31052698K. So I refrained from checking what I intended on Sm, and went on with the bug day. I've been testing the Minefield build from 2007-04-09. Created lots of profiles with that and older builds, no crash. At the evening/night, I've updated it to a 2007-04-10 one. Some unknown time after that, with the last profile selected, on Create profile button press, it crashed, and - I am not sure, but I think it was so - the selected profile has disappeared. Then it was crashing sometimes in such a case. No Talkback client has started from that. Then I downloaded Thunderbird from 2007-04-10, and it had the same problems, except that no profile disappeared, for sure. Thoughts: 1. The crashes of the latter two don't seem to be caused by profiles.ini - it didn't seem to change (Seamonkey doesn't seem to have a profiles.ini, and seems to be using binary files to store that information; I've saved them). 2. Seamonkey crashes most of the time, Thunderbird much rarer, and Minefield has (almost?) stopped to crash (but maybe that's just me testing it less ATM). 3. Crashes seem to be more likely when the last profile in the list is selected. No tests were tried without the existing profile folder or on a different Debian machine. No PM crashes were by others are known as of yet. PS: When testing the Minefield build, it crashed on Ctrl-U (as they sometimes do), and the Talkback report had a similar stack: TB31065366H.

Looks like this may have been caused by one of the accessibility checkins during that time. http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-04-09+03&maxdate=2007-04-10+05&cvsroot=%2Fcvsroot Incident ID: 31052677 Stack Signature 0xafcbda46 d416bffd Product ID MozillaTrunk Build ID 2007041001 Trigger Time 2007-04-10 06:59:24.0 Platform LinuxIntel Operating System Linux 2.6.17-2-686 Module URL visited User Comments When I unpacked this build, I've accidentally started it with my default profile, and pressed Ctrl-C to stop it. Next time, this. Since Last Crash 0 sec Total Uptime 0 sec Trigger Reason SIGSEGV: Segmentation Fault: (signal 11) Source File, Line No. N/A Stack Trace 0xafcbda46 nsCOMPtr_base::assign_from_qi() [mozilla/objdir/xpcom/build/nsCOMPtr.cpp, line 526] nsAccessibilityService::GetRelevantContentNodeFor() nsRootAccessible::FireCurrentFocusEvent() nsRootAccessible::FireFocusCallback() nsTimerImpl::Fire() nsTimerEvent::Run() nsThread::ProcessNextEvent() NS_ProcessNextEvent_P() [mozilla/objdir/xpcom/build/nsThreadUtils.cpp, line 227] nsXULWindow::ShowModal() nsContentTreeOwner::ShowAsModal() nsWindowWatcher::OpenWindowJSInternal() nsWindowWatcher::OpenWindowJS() nsGlobalWindow::OpenInternal() nsGlobalWindow::OpenDialog() NS_InvokeByIndex() XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)() XPC_WN_CallMethod() js_Invoke() js_Interpret() js_Invoke() js_InternalInvoke() JS_CallFunctionValue() nsJSContext::CallEventHandler() nsJSEventListener::HandleEvent() nsEventListenerManager::HandleEventSubType() nsEventListenerManager::HandleEvent() nsEventTargetChainItem::HandleEvent() nsEventTargetChainItem::HandleEventTargetChain() nsEventDispatcher::Dispatch() PresShell::HandleDOMEventWithTarget() nsButtonBoxFrame::DoMouseClick() nsButtonBoxFrame::MouseClicked() nsButtonBoxFrame::HandleEvent() nsPresShellEventCB::HandleEvent() nsEventTargetChainItem::HandleEventTargetChain() nsEventDispatcher::Dispatch() PresShell::HandleEventInternal() PresShell::HandleEventWithTarget() nsEventStateManager::CheckForAndDispatchClick() nsEventStateManager::PostHandleEvent() PresShell::HandleEventInternal() PresShell::HandlePositionedEvent() PresShell::HandleEvent() nsViewManager::HandleEvent() nsViewManager::DispatchEvent() HandleEvent() nsCommonWidget::DispatchEvent() nsWindow::OnButtonReleaseEvent() button_release_event_cb() libgtk-x11-2.0.so.0 + 0x12e250 (0xa7c3c250) libgobject-2.0.so.0 + 0x998b (0xa79dc98b) libgobject-2.0.so.0 + 0x19f2d (0xa79ecf2d) libgobject-2.0.so.0 + 0x1b208 (0xa79ee208) libgobject-2.0.so.0 + 0x1b5d9 (0xa79ee5d9) libgtk-x11-2.0.so.0 + 0x217f64 (0xa7d25f64) libgtk-x11-2.0.so.0 + 0x127bd3 (0xa7c35bd3) libgtk-x11-2.0.so.0 + 0x128e07 (0xa7c36e07) libgdk-x11-2.0.so.0 + 0x42eea (0xa7ab5eea) libglib-2.0.so.0 + 0x2b731 (0xa796c731) libglib-2.0.so.0 + 0x2e7a6 (0xa796f7a6) libglib-2.0.so.0 + 0x2ed27 (0xa796fd27) nsAppShell::ProcessNextNativeEvent() nsBaseAppShell::DoProcessNextNativeEvent() nsBaseAppShell::OnProcessNextEvent() nsThread::ProcessNextEvent() NS_ProcessNextEvent_P() [mozilla/objdir/xpcom/build/nsThreadUtils.cpp, line 227] nsXULWindow::ShowModal() nsContentTreeOwner::ShowAsModal() nsWindowWatcher::OpenWindowJSInternal() nsWindowWatcher::OpenWindow() nsProfile::LoadDefaultProfileDir() nsProfile::StartupWithArgs() nsAppStartup::DoProfileStartup() main1

2007041304: Minefield now crashes after the startup restore dialog, and on tab switching or menu (not sure which, or both), but I can't get past the first of them anymore. 2007041504: Minefield with a new profile has crashed only once yet, with TB31208134H, that seems to be a different thing. With the profile from 2007041304, crashes after that dialog.

I can confirm the crash

Ginn & Evan, I get a core dumped message to the console. How do I get a stack trace from that on Ubuntu?

For me it doesn't crash when gdb is running. 106 aTargetNode->GetLocalName(localName); That would lead me to believe that aTargetNode is nsnull, but it isn't. That method is only called if the node is non-null.

The crash is intermittent. After putting some printfs in the code I get a slightly different crash stack. The common part is that a new window opens, we fire a timer, that tries to call into nsRootAccessible, and we crash somewhere. Perhaps it's a dead nsRootAccessible at that point.

Ginn, do you have any ideas?

I can't reproduce the bug, but I have a hunch... does this help?

> I can't reproduce the bug, but I have a hunch... Do you have accessibility enabled on your desktop? > does this help? It doesn't help.

This bug is fixed by Ginn's patch in bug 377732.

I'm sorry I forgot this one before I post a new one. Looks like same issue.