170465 - Crash canceling the mail account wizard [@ nsMsgIncomingServer::GetFilterList][@ nsMsgIncomingServer::InternalSetHostName][@ nsMsgIncomingServer::OnUserOrHostNameChanged]

Status: VERIFIED DUPLICATE of bug 172586

(SeaMonkey :: MailNews: Account Configuration, defect)

Description

[greer]

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

Comment 1

[greer]

Attachment: Registers and values at the time of crash

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

Comment 2

[greer]

Related to 143824 I would imagine.

Comment 3

[David Bradley]

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

Comment 4

[Troodon]

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.

Comment 5

[greer]

Attachment: Talkback stack from the incident in the previous comment

Comment 6

[greer]

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.

Comment 7

[Troodon]

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

Comment 8

[greer]

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

Comment 9

[David Bradley]

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.

Comment 10

[greer]

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

Comment 11

[greer]

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

Comment 12

[greer]

Attachment: Stack

Alternate stack for 'nsMsgIncomingServer::OnUserOrHostNameChanged' signature

Comment 13

[David Bradley]

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.

Comment 14

[Frank Wein [:mcsmurf]]

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

Comment 15

[Myk Melez [:myk] [@mykmelez]]

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.

Comment 16

[John "AntiTuX" Dee]

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

Comment 17

[David Bradley]

How did you install this version of Mozilla, Myk?

Comment 18

[David Bradley]

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.

Comment 19

[Tuukka Tolvanen (sp3000)]

fwiw, bug 170685 comment 8

Comment 20

[David G King]

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

Comment 21

[varada]

Taking from racham who is on sabbatical.

Comment 22

[Myk Melez [:myk] [@mykmelez]]

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

Comment 23

[Asa Dotzler [:asa]]

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. 

Comment 24

[(not reading, please use [e-mail] instead)]

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.

Comment 25

[(not reading, please use [e-mail] instead)]

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."

Comment 26

[Asa Dotzler [:asa]]

OK.

Comment 27

[Myk Melez [:myk] [@mykmelez]]

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.

Comment 28

[(not reading, please use [e-mail] instead)]

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"

Comment 29

[Ere Maijala (slow)]

"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.

Comment 30

[Jay Patel [:jay]]

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?

Comment 31

[Jay Patel [:jay]]

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

Comment 32

[Brian Ryner (not reading)]

I suspect it is.

Comment 33

[David Bradley]

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

Comment 34

[Troodon]

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

Comment 35

[Daniel Steinberger]

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)

Comment 36

[(not reading, please use [e-mail] instead)]

moving out to 1.3 beta

Comment 37

[Brian Ryner (not reading)]

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

Comment 38

[Vedran Miletic]

v