Closed Bug 105670 Opened 23 years ago Closed 22 years ago

Crash launching Messenger/new msg/AddressB using migrated profile/default user name - Trunk, M095, N622 [@ nsMsgAccountManager::GetDefaultAccount]

Categories

(MailNews Core :: Profile Migration, defect)

x86
Windows NT
defect
Not set
critical

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: yulian, Assigned: racham)

References

Details

(Keywords: crash, topcrash+)

Crash Data

Attachments

(4 files, 4 obsolete files)

20011017 0.9.4 windows builds on NT & 2000.

Launching Messengerwindow, New message window or Address Book window crashed if
using migrated profile which contains "default" as User name for Outgoing mail
server and Incoming Mail Server name as the user name for Incoming Mail Server.

This kind of mail account in 4.x is not useful but doesn't crash. But once get
migrated to 6.2, it causes problems. This case is rare or even invalid but
causing crashes is a problem.

1. Create a new profile in 4.x as usual except the following steps:
   1a. In "Set Up Your Incoming Mail Server" dialog, enter incoming mail server
name as Mail server user name. For example, linzilla.mcom.com as Mail server
user name.
   1b. choose IMAP mail server type
 See screen shot to follow

2. finish creating profile
3. Launch Preferences window...Edit|Preferences and choose Mail&Newsgroups|Mail
Servers category in Communicator
4. Enter default in "Outgoing Mail server user name:" text field
 See screen shot to follow

5. Migrated this profile file to 6.2 and launch it
6. File|New|Message to launch compose window or Tasks| Mail&Newsgroups to launch
messenger or Tasks|Addres Book to launch Address Book window

Actual results: Compose window, Messenger or Address Book window is up but hangs
 then crashes

Expected result: no crash

Please refer to talk back report, Incident ID 36844674, 36843468 and 36838103. 
http://cyclone/reports/SingleIncidentInfo.cfm?dynamicBBID=36843468

Stack Trace
nsMsgAccountManager::GetDefaultAccount
[d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgAccountManager.cpp, line 757]
XPTC_InvokeByIndex
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp,
line 139]
XPCWrappedNative::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp, line 1954]
XPC_WN_GetterSetter
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp,
line 1295]
js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 809]
js_InternalInvoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 900]
js_GetProperty [d:\builds\seamonkey\mozilla\js\src\jsobj.c, line 2433]
js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2559]
js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 825]
js_InternalInvoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 900]
JS_CallFunctionValue [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 3364]
nsJSContext::CallEventHandler
[d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 959]
nsJSEventListener::HandleEvent
[d:\builds\seamonkey\mozilla\dom\src\events\nsJSEventListener.cpp, line 140]
nsEventListenerManager::HandleEventSubType
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line
1197]
nsEventListenerManager::HandleEvent
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line
1872]
GlobalWindowImpl::HandleDOMEvent
[d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 605]
DocumentViewerImpl::LoadComplete
[d:\builds\seamonkey\mozilla\content\base\src\nsDocumentViewer.cpp, line 1086]
nsDocShell::EndPageLoad
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 3750]
nsWebShell::EndPageLoad
[d:\builds\seamonkey\mozilla\docshell\base\nsWebShell.cpp, line 898]
nsDocShell::OnStateChange
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 3671]
nsDocLoaderImpl::FireOnStateChange
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp, line 1095]
nsDocLoaderImpl::doStopDocumentLoad
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp, line 734]
nsDocLoaderImpl::DocLoaderIsEmpty
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp, line 632]
nsDocLoaderImpl::OnStopRequest
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp, line 563]
nsLoadGroup::RemoveRequest
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsLoadGroup.cpp, line 521]
imgRequestProxy::OnStopRequest
[d:\builds\seamonkey\mozilla\modules\libpr0n\src\imgRequestProxy.cpp, line 385]
imgRequest::OnStopRequest
[d:\builds\seamonkey\mozilla\modules\libpr0n\src\imgRequest.cpp, line 685]
ProxyListener::OnStopRequest
[d:\builds\seamonkey\mozilla\modules\libpr0n\src\imgLoader.cpp, line 455]
nsJARChannel::OnStopRequest
[d:\builds\seamonkey\mozilla\netwerk\protocol\jar\src\nsJARChannel.cpp, line 582]
nsOnStopRequestEvent::HandleEvent
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsRequestObserverProxy.cpp, line 162]
PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 591]
PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c,
line 524]
_md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line
1072]
Attachment #54222 - Attachment is obsolete: true
Attachment #54223 - Attachment is obsolete: true
Attachment #54225 - Attachment is obsolete: true
Attachment #54227 - Attachment is obsolete: true
QA Contact: esther → nbaca
reassigning to racham.  This looks like a dup of 105337
Assignee: sspitzer → racham
*** Bug 106100 has been marked as a duplicate of this bug. ***
Comment on attachment 54894 [details] [diff] [review]
patch, v1 - Adding a null check on incoming server

sr=sspitzer
Attachment #54894 - Flags: superreview+
*** Bug 105337 has been marked as a duplicate of this bug. ***
Adding crash, topcrash keywords and Trunk, M095, N620 [@
nsMsgAccountManager::GetDefaultAccount] to summary. This crash has been showing
up as a topcrasher on those release/builds.
Keywords: crash, topcrash
Summary: Crash launching Messenger/new msg/AddressB using migrated profile/default user name → Crash launching Messenger/new msg/AddressB using migrated profile/default user name - Trunk, M095, N620 [@ nsMsgAccountManager::GetDefaultAccount]
Do you know if the email addresses for this crash are all from the same person?

Also, when Esther and I looked at the Talkback traces for
nsMsgAccountManager::GetDefaultAccount, we noticed that the second line of some
of these stack traces did not point to xptcinvoke.cpp.  Could this stack trace
be a summary of other types of problems not specific to what Yulian reported
which is an invalid server name being migrated from 4.x?
Keywords: nsbeta1
Will check in as soon as tree is open.
Status: NEW → ASSIGNED
Keywords: nsbeta1
All of the recent N620 branch crashes were submitted by gchan@netscape.com, 
esther@netscape.com or yulian@netscape.com.  Others have crashed with recent
MozillaTrunk builds and Mozilla 0.9.5 as well, but I can't post their emails here.
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Trunk build 2001-11-15: WinMe, Mac 9.1
Verified Fixed, no longer crashes.
Status: RESOLVED → VERIFIED
*** Bug 110562 has been marked as a duplicate of this bug. ***
N622 data has 104 user crashes with the same signature and similar steps (N621 
also has 158). I'll attach the current comments below. Reopening. Did this fix 
make it into the commercial branch for N621?
Severity: normal → critical
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Summary: Crash launching Messenger/new msg/AddressB using migrated profile/default user name - Trunk, M095, N620 [@ nsMsgAccountManager::GetDefaultAccount] → Crash launching Messenger/new msg/AddressB using migrated profile/default user name - Trunk, M095, N622 [@ nsMsgAccountManager::GetDefaultAccount]
What a coincident...just when I try to port this into our N621/N622 Sun branch,
I see greer@netscape.com's comment.  I can answer this question.  No, this bug
does not make it to N621 and N622 as far as I can tell.  Our branch is based on
N621, we see the crash.  We have recently integrated all N622 bug fixes into our
branch, and yet we can still see the crash.  We see the exact same stack trace. 
However, the way we reproduce the bug is different.  Below is how we reproduce
it:

1. Run our enterprise version of N4.76
2. Run N6.2.x the very first time.  This involves profile migration
3. Bring up mail (IMAP as mail.server_type as this is how we setup in N4.76). 

The mail window shows up, then it crashes right away.

Interesting enough if we do not run the enterprise version of N4.76, instead we
run a user installed version of N4.76, the crash does not occur.

We have done some investigations on this issue.  What we have seen is that, the
way that our enterprise N4.76 set up is different from our user installed
version.  The preferences.js file is generated differently.  The enterprise
N4.76 has used MCD to set up some enterprise configurations.  With this
configuration, we see that some of the preferences have some inconsistencies the
way it references the mail server, e.g., 

   user_pref("mail.imap.server.trees.PRC.capability", 81);
   user_pref("mail.imap.server.trees.admin_url", "");
   user_pref("mail.imap.server.trees.check_new_mail", true);

where "trees" is one of our mail server, and "PRC" is one of our domain name. 
If we have preferences with some containing the domain name and some do not,
then we will see the crash right away.  If we hand edit the preferences to make
them consistent, either all go with domainname or all go without, then the crash
does not happen.  

This is a problem for our enterprise deployment.  As this way of referencing our
mail server does not cause us any trouble in any 4.7x migration, but it does
crash when we migrate to 6.2.x.  
topcrash -> topcrash+ and nominating for nsbeta1

Keywords: topcrashnsbeta1, topcrash+
Keywords: nsbeta1nsbeta1+
Whiteboard: [adt1]
Is this bug happening in the daily commercial trunk builds?   

If this is not, then this should not be nsbeta1+ and this bug should be closed
fixed again (for trunk) and contents copied to bugscape (for future 6.2.x
development, if any).

If yes, then we can leave this bug as is.
Not showing up in trunk or M099 topcrash reports, but does show up in N622 reports
The patch is in the trunk, so I would expect that the crash won't happen on
trunk.  Although after we patch the crash, we are still struggling with some
migration issues which is probably caused by some unknown status of the MCD/NADM
tools used by N62x.  My previous update simply tries to reply  to
greer@netscape.com's that this problem does exist in N62x as of today.  Perhaps
what Lisa has suggested is the right approach for the continuation of this
issue.
taking off Mach V radar.
Keywords: nsbeta1+
Whiteboard: [adt1]
Why was this taken off the MachV radar. Is it because it was no longer showing
up in M099 topcrash reports, or the trunk?
Jaime, read comment 25
Closing this out as Fixed.  Talkback data only shows this crashing with Netscape
6.20, 6.21 and 6.22.  There are 0 incidents for any other Mozilla milestone or
MozillaTrunk build.  

If this does somehow come back in the next Netscape release, we'll have to take
a closer look.  This might be a very specific crash that only happens on
Netscape releases (which would explain why there aren't any crashes with Mozilla
builds)...but for now it doesn't seem to be an issue.
Status: REOPENED → RESOLVED
Closed: 23 years ago22 years ago
Resolution: --- → FIXED
Verifying this CRASH fixed based on Talkback data.  If there are any remaining
issues related to this problem please log a new bug.
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
Crash Signature: [@ nsMsgAccountManager::GetDefaultAccount]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: