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



17 years ago
14 years ago


(Reporter: greer, Assigned: sspitzer)


({crash, qawanted, topcrash})

Windows 98
crash, qawanted, topcrash

Firefox Tracking Flags

(Not tracked)


(crash signature)


(3 attachments)



17 years ago
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: 

[c:/builds/seamonkey/mozilla/mailnews/base/util/nsMsgIncomingServer.cpp  line 1068]
	 nsXPTCStubBase::Stub91	[../../../../../../dist/include/xpcom\
 line 94]
[c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp  line 1996]
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]
[c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp  line 1195]
[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]
[c:/builds/seamonkey/mozilla/content/events/src/nsEventListenerManager.cpp  line
[c:/builds/seamonkey/mozilla/content/events/src/nsEventListenerManager.cpp  line
[c:/builds/seamonkey/mozilla/content/xul/content/src/nsXULElement.cpp  line 3579]
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp  line 6233]
[c:/builds/seamonkey/mozilla/layout/xul/base/src/nsTextBoxFrame.cpp  line 502]
[c:/builds/seamonkey/mozilla/layout/xul/base/src/nsTextBoxFrame.cpp  line 415]
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp  line 6199]
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp  line 6149]
[c:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp  line 2856]
[c:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp  line 1858]
[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]
[c:/builds/seamonkey/mozilla/view/src/nsViewManager.cpp  line 2150]
	 nsView::HandleEvent	[c:/builds/seamonkey/mozilla/view/src/nsView.cpp  line 301]
[c:/builds/seamonkey/mozilla/view/src/nsViewManager.cpp  line 1903]
	 HandleEvent	[c:/builds/seamonkey/mozilla/view/src/nsView.cpp  line 83]
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp  line 1016]
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp  line 1050]
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp  line 5131]
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp  line 5386]
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp  line 3838]
[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)
[c:/builds/seamonkey/mozilla/xpfe/appshell/src/nsContentTreeOwner.cpp  line 460]
 line 745]
[c:/builds/seamonkey/mozilla/dom/src/base/nsGlobalWindow.cpp  line 4248]
[c:/builds/seamonkey/mozilla/dom/src/base/nsGlobalWindow.cpp  line 3016]
	 nsXPTCStubBase::Stub91	[../../../../../../dist/include/xpcom\
 line 94]
[c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp  line 1996]
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]
[c:/builds/seamonkey/mozilla/dom/src/base/nsJSEnvironment.cpp  line 702]
[c:/builds/seamonkey/mozilla/dom/src/base/nsGlobalWindow.cpp  line 4587]
[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)
[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


17 years ago
Keywords: crash, qawanted, topcrash

Comment 1

17 years ago
Created attachment 100372 [details]
Registers and values at the time of crash

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

Comment 2

17 years ago
Related to 143824 I would imagine.

Comment 3

17 years ago
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

17 years ago
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

17 years ago
Created attachment 100936 [details]
Talkback stack from the incident in the previous comment

Comment 6

17 years ago
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.
Summary: Crash canceling the mail account wizard [@ nsMsgIncomingServer::GetFilterList] → Crash canceling the mail account wizard [@ nsMsgIncomingServer::GetFilterList][@ nsMsgIncomingServer::InternalSetHostName]

Comment 7

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

Comment 8

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

Comment 9

16 years ago
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

Also the stack register and frame register both have the same values as bug 143824.

Comment 10

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

Comment 11

16 years ago
The user comments under nsMsgIncomingServer::OnUserOrHostNameChanged (M1.2a)
indicate the same behavior is crashing with this signature also.
Summary: Crash canceling the mail account wizard [@ nsMsgIncomingServer::GetFilterList][@ nsMsgIncomingServer::InternalSetHostName] → Crash canceling the mail account wizard [@ nsMsgIncomingServer::GetFilterList][@ nsMsgIncomingServer::InternalSetHostName][@ nsMsgIncomingServer::OnUserOrHostNameChanged]

Comment 12

16 years ago
Created attachment 101303 [details]

Alternate stack for 'nsMsgIncomingServer::OnUserOrHostNameChanged' signature

Comment 13

16 years ago
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.
Severity: critical → blocker
Keywords: smoketest
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

16 years ago
How did you install this version of Mozilla, Myk?

Comment 18

16 years ago
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 20

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

Comment 21

16 years ago
Taking from racham who is on sabbatical.
Assignee: racham → varada
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.
Assignee: varada → sspitzer
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."
Keywords: smoketest
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.
Target Milestone: --- → mozilla1.2beta

Comment 30

16 years ago
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

16 years ago
cc'ing bryner and dveditz for their this a dup of bug 172586 also guys?
I suspect it is.

Comment 33

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

Comment 34

16 years ago
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
Target Milestone: mozilla1.2beta → mozilla1.3beta

*** This bug has been marked as a duplicate of 172586 ***
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE

Comment 38

16 years ago
Product: Browser → Seamonkey
Crash Signature: [@ nsMsgIncomingServer::GetFilterList] [@ nsMsgIncomingServer::InternalSetHostName] [@ nsMsgIncomingServer::OnUserOrHostNameChanged]
You need to log in before you can comment on or make changes to this bug.