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)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: yulian, Assigned: racham)
References
Details
(Keywords: crash, topcrash+)
Crash Data
Attachments
(4 files, 4 obsolete files)
39.83 KB,
image/jpeg
|
Details | |
65.49 KB,
image/jpeg
|
Details | |
745 bytes,
patch
|
sspitzer
:
superreview+
|
Details | Diff | Splinter Review |
10.78 KB,
text/plain
|
Details |
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]
Reporter | ||
Comment 1•23 years ago
|
||
Reporter | ||
Comment 2•23 years ago
|
||
Reporter | ||
Updated•23 years ago
|
Attachment #54222 -
Attachment is obsolete: true
Reporter | ||
Updated•23 years ago
|
Attachment #54223 -
Attachment is obsolete: true
Reporter | ||
Comment 3•23 years ago
|
||
Reporter | ||
Updated•23 years ago
|
Attachment #54225 -
Attachment is obsolete: true
Reporter | ||
Comment 4•23 years ago
|
||
Reporter | ||
Updated•23 years ago
|
Attachment #54227 -
Attachment is obsolete: true
Reporter | ||
Comment 5•23 years ago
|
||
Reporter | ||
Comment 6•23 years ago
|
||
Comment 7•23 years ago
|
||
reassigning to racham. This looks like a dup of 105337
Assignee: sspitzer → racham
Comment 8•23 years ago
|
||
*** Bug 106100 has been marked as a duplicate of this bug. ***
Comment 10•23 years ago
|
||
Comment on attachment 54894 [details] [diff] [review] patch, v1 - Adding a null check on incoming server sr=sspitzer
Attachment #54894 -
Flags: superreview+
Comment 11•23 years ago
|
||
*** Bug 105337 has been marked as a duplicate of this bug. ***
Comment 12•23 years ago
|
||
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.
Comment 13•23 years ago
|
||
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
Assignee | ||
Comment 14•23 years ago
|
||
Will check in as soon as tree is open.
Status: NEW → ASSIGNED
Keywords: nsbeta1
Comment 15•23 years ago
|
||
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.
Assignee | ||
Comment 16•23 years ago
|
||
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 17•23 years ago
|
||
Trunk build 2001-11-15: WinMe, Mac 9.1 Verified Fixed, no longer crashes.
Status: RESOLVED → VERIFIED
Assignee | ||
Comment 18•23 years ago
|
||
*** Bug 110562 has been marked as a duplicate of this bug. ***
Comment 19•22 years ago
|
||
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]
Comment 20•22 years ago
|
||
Comment 21•22 years ago
|
||
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.
Comment 22•22 years ago
|
||
topcrash -> topcrash+ and nominating for nsbeta1
Updated•22 years ago
|
Comment 23•22 years ago
|
||
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.
Comment 24•22 years ago
|
||
Not showing up in trunk or M099 topcrash reports, but does show up in N622 reports
Comment 25•22 years ago
|
||
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.
Comment 27•22 years ago
|
||
Why was this taken off the MachV radar. Is it because it was no longer showing up in M099 topcrash reports, or the trunk?
Comment 28•22 years ago
|
||
Jaime, read comment 25
Comment 29•22 years ago
|
||
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 ago → 22 years ago
Resolution: --- → FIXED
Comment 30•22 years ago
|
||
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
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
Updated•13 years ago
|
Crash Signature: [@ nsMsgAccountManager::GetDefaultAccount]
You need to log in
before you can comment on or make changes to this bug.
Description
•