This stack shows up as a topcrash in M1.2a. It also has a few incidents on the M1BR branch, but only as recently as the 9/14 build. The signature is also appearing in M1.1 (MozillaTrunk) and M1.0.1 (Gecko1.0 branch) both from 8/26. There are no incidents in current Trunk data. Having said that, this one may still be a problem. Most users do not use the Trunk and Branch builds for the mail client and it is not as likely to be a crasher in those builds. Is there a fix that might have remedied this crash since the 9/14 build? If I am missing a previous bug for this signature, please dupe it. Here are the user comments that might indicate the steps to crash this one (using the M1.2a build): (11031835) Comments: I've started the Mail/news module and it was answering me again for previous e-mail accounts informations (10920871) Comments: second crash. same thing. account wizard insisted on running first crashes when you press the cancel button. also previous crash changed my default theme from pinball to classic (10920862) Comments: open with an account wizard execution crashes when you select cancel. happened twice now Stack Trace: nsMsgIncomingServer::GetFilterList [c:/builds/seamonkey/mozilla/mailnews/base/util/nsMsgIncomingServer.cpp line 1068] nsXPTCStubBase::Stub91 [../../../../../../dist/include/xpcom\xptcstubsdef.inc line 94] XPCWrappedNative::CallMethod [c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp line 1996] XPC_WN_GetterSetter [c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp line 1299] js_Execute [c:/builds/seamonkey/mozilla/js/src/jsinterp.c line 963] js_CheckRedeclaration [c:/builds/seamonkey/mozilla/js/src/jsinterp.c line 1201] js_SetProperty [c:/builds/seamonkey/mozilla/js/src/jsobj.c line 2596] js_Interpret [c:/builds/seamonkey/mozilla/js/src/jsinterp.c line 2668] js_Execute [c:/builds/seamonkey/mozilla/js/src/jsinterp.c line 968] Function [c:/builds/seamonkey/mozilla/js/src/jsfun.c line 1685] js_Execute [c:/builds/seamonkey/mozilla/js/src/jsinterp.c line 963] js_Interpret [c:/builds/seamonkey/mozilla/js/src/jsinterp.c line 2842] js_Execute [c:/builds/seamonkey/mozilla/js/src/jsinterp.c line 968] js_Interpret [c:/builds/seamonkey/mozilla/js/src/jsinterp.c line 2842] js_Execute [c:/builds/seamonkey/mozilla/js/src/jsinterp.c line 968] nsXPCWrappedJSClass::CallMethod [c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp line 1195] nsXPCWrappedJS::CallMethod [c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp line 430] XPT_Do64 [c:/builds/seamonkey/mozilla/xpcom/typelib/xpt/src/xpt_xdr.c line 581] CheckForRepeat [c:/builds/seamonkey/mozilla/xpcom/typelib/xpt/src/xpt_xdr.c line 521] nsEventListenerManager::HandleEventSubType [c:/builds/seamonkey/mozilla/content/events/src/nsEventListenerManager.cpp line 1179] nsEventListenerManager::HandleEvent [c:/builds/seamonkey/mozilla/content/events/src/nsEventListenerManager.cpp line 2127] nsXULElement::GetResource [c:/builds/seamonkey/mozilla/content/xul/content/src/nsXULElement.cpp line 3579] PresShell::ResizeReflow [c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp line 6233] nsTextBoxFrame::CalculateUnderline [c:/builds/seamonkey/mozilla/layout/xul/base/src/nsTextBoxFrame.cpp line 502] nsTextBoxFrame::PaintTitle [c:/builds/seamonkey/mozilla/layout/xul/base/src/nsTextBoxFrame.cpp line 415] PresShell::HandleDOMEventWithTarget [c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp line 6199] PresShell::HandleEventInternal [c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp line 6149] nsEventStateManager::CheckForAndDispatchClick [c:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp line 2856] nsEventStateManager::PostHandleEvent [c:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp line 1858] PresShell::HandleDOMEventWithTarget [c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp line 6205] InClipRect [c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp line 5773] nsViewManager::GrabKeyEvents [c:/builds/seamonkey/mozilla/view/src/nsViewManager.cpp line 2150] nsView::HandleEvent [c:/builds/seamonkey/mozilla/view/src/nsView.cpp line 301] nsViewManager::DispatchEvent [c:/builds/seamonkey/mozilla/view/src/nsViewManager.cpp line 1903] HandleEvent [c:/builds/seamonkey/mozilla/view/src/nsView.cpp line 83] nsWindow::InitEvent [c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp line 1016] nsWindow::DispatchEvent [c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp line 1050] nsWindow::DispatchMouseEvent [c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp line 5131] ChildWindow::DispatchMouseEvent [c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp line 5386] nsWindow::ProcessMessage [c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp line 3838] nsWindow::WindowProc [c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp line 1300] USER32.dll + 0x3a5f (0x77d43a5f) USER32.dll + 0x3b2e (0x77d43b2e) USER32.dll + 0x3d6a (0x77d43d6a) USER32.dll + 0x41fd (0x77d441fd) nsContentTreeOwner::ExitModalEventLoop [c:/builds/seamonkey/mozilla/xpfe/appshell/src/nsContentTreeOwner.cpp line 460] nsWindowWatcher::OpenWindowJS [c:/builds/seamonkey/mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp line 745] GlobalWindowImpl::OpenInternal [c:/builds/seamonkey/mozilla/dom/src/base/nsGlobalWindow.cpp line 4248] GlobalWindowImpl::OpenDialog [c:/builds/seamonkey/mozilla/dom/src/base/nsGlobalWindow.cpp line 3016] nsXPTCStubBase::Stub91 [../../../../../../dist/include/xpcom\xptcstubsdef.inc line 94] XPCWrappedNative::CallMethod [c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp line 1996] XPC_WN_CallMethod [c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp line 1267] js_Execute [c:/builds/seamonkey/mozilla/js/src/jsinterp.c line 963] js_Interpret [c:/builds/seamonkey/mozilla/js/src/jsinterp.c line 2842] js_Interpret [c:/builds/seamonkey/mozilla/js/src/jsinterp.c line 1386] JS_EvaluateUCScriptForPrincipals [c:/builds/seamonkey/mozilla/js/src/jsapi.c line 3384] nsJSContext::EvaluateString [c:/builds/seamonkey/mozilla/dom/src/base/nsJSEnvironment.cpp line 702] GlobalWindowImpl::RunTimeout [c:/builds/seamonkey/mozilla/dom/src/base/nsGlobalWindow.cpp line 4587] GlobalWindowImpl::TimerCallback [c:/builds/seamonkey/mozilla/dom/src/base/nsGlobalWindow.cpp line 4952] nsProcess::Run [c:/builds/seamonkey/mozilla/xpcom/threads/nsProcessCommon.cpp line 296] USER32.dll + 0x6e60 (0x77d46e60) nsAppShellService::Quit [c:/builds/seamonkey/mozilla/xpfe/appshell/src/nsAppShellService.cpp line 500] main1 [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp line 1525] main [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp line 1871] Source File : c:/builds/seamonkey/mozilla/mailnews/base/util/nsMsgIncomingServer.cpp line : 1068

Looking at the registers it looks like the code is dereferencing a null pointer.

Related to 143824 I would imagine.

It's definitely an interface info problem. Tell tale sign of XPConnect's XPC_WN_GetterSetter function invoking a non-getter/setter function. What's a little mystifying is that getFilterList is before shutdown, and so the addition of shutdown shouldn't have caused the problem

I had/have this bug with all the nightly builds (last was 20020924) I tried to install after 1.2a (20020914). The talkback ID is TB11556113W.

This crash is also showing up as a topcrash for M1.2a under the nsMsgIncomingServer::InternalSetHostName signature. Adding that to the suumary to please the Talkback automation.

I son't know why the talkback report shows "2002091014" as build ID because that report was made using build 2002092408.

*** Bug 171557 has been marked as a duplicate of this bug. ***

I think this and bug 143824 may be cause by the same problem. They both have strange stacks. They also both jump to similar invalid locations: 77e7eb69 50 push eax 77e7eb6a e8da50ffff call 77e73c49 77e7eb6f cc int 3 This is the same instruction sequence in the other bug. This code location is either completely invalid or is off by one or two bytes. Also it could be a talkback problem, disassembling the object code, but I haven't noticed this elsewhere. Also the stack register and frame register both have the same values as bug 143824.

*** Bug 171900 has been marked as a duplicate of this bug. ***

The user comments under nsMsgIncomingServer::OnUserOrHostNameChanged (M1.2a) indicate the same behavior is crashing with this signature also.

Alternate stack for 'nsMsgIncomingServer::OnUserOrHostNameChanged' signature

That's another odd stack. In that case, there's really no way for XPCWrappedNative::CallMethod to call nr_GetUsername nor anyway for nr_GetUsername to call nsMsgIncomingServer::OnUserOrHostNameChanged. This looks like the stack has been corrupted. If anyone could reproduce this, we might be able to log what XPConnect is invoking and find out what the actual function is that XPConnect is calling. That might give us the function that is corrupting the stack.

*** Bug 172114 has been marked as a duplicate of this bug. ***

I can reproduce on Windows 2002-10-02-08 with a fresh profile. Talkback incident ID 11941820. This should be a smoketest blocker, since it makes MailNews completely unusable with no workaround.

I haven't seen this issue, and it's not something I check for during smoketests. I would say it's a blocker though.

How did you install this version of Mozilla, Myk?

Seth added Shutdown to nsIMsgIncomingServer. Don't know if that or the surrounding code has anything to do with this problem or not. I'm sure the Shutdown addition caused stale interface info issue, but we're past that now.

fwiw, bug 170685 comment 8

As the tree is OPEN, I assume this isn't really a Smoketest Blocker.

Taking from racham who is on sabbatical.

I installed using "mozilla-win32-installer-sea.exe" onto an older version of Mozilla from August 23.

This is a smoketest blocker. Why on earth did the tree open yesterday!? Varada, we're going to need traction on this before the tree opens today.

this is either: 1) me 2) an install issue. myk: not important if a fresh profile. what matters is where you installed (on top of an existing mozilla, or in a new dir) I think someone (david bradley) suggested I re-arrange my fix to avoid this problem, but there seems to be something serious here, outside my fix.

I don't think this is a smoketest blocker. my guess is the reason our smoketesters don't see it, is they (like the rest of QA), usually install to a new dir each time. twalker, please correct me if I'm wrong. I'll try to re-arrange like dbradley suggested. but I'd feel better if someone said: "oh, it's an installer [xpconnect?] issue, see bug #xxxxxxx. but until it's fixed, re-arrange your code."

OK.

I can't reproduce on the original machine because it's in the office and I'm at home, but on another machine here I was able to confirm that problems I had installing that build on top of an older release went away when I did a fresh install, so it looks like this is an install problem.

I don't think this is smoketest blocker worthy. (I wouldn't hold the tree for it.) the code re-arranging I plan on trying is from this suggestion from dbradley: "It would help if people added new methods/attributes at the end"

"oh, it's an installer issue, see bug 162593. but until it's fixed, re-arrange your code." Oops, that one's supposed to be fixed, and I'm not sure if that's the problem, but sounds very similar.

Looking at Talkback data, I don't see any crashes like this on the MozillaTrunk after 10/7. Did another checkin on that date perhaps fix this issue? I suspect that this was fixed by the changes made for bug 172586...but can't be sure. All of the crashes duped to that bug also stopped showing up in Talkback data after 10/7. Dup?

cc'ing bryner and dveditz for their input...is this a dup of bug 172586 also guys?

I suspect it is.

Most likely it is. These all tie back to the interface change Seth made to add Shutdown.

I tested with build 2002101611 and all worked fine (no acccount wizard, no crashes).

for me it came out to be bug 172586 - i didn't clean up mozillas install directory. after i did, everything went back to normal. jay seems to be right (dup)

moving out to 1.3 beta

*** This bug has been marked as a duplicate of 172586 ***

v