Closed Bug 723105 Opened 13 years ago Closed 12 years ago

crash CrashInJS | nsMsgIdentity::SetFullName | nsOutlookCompose::CreateIdentity


(MailNews Core :: Import, defect)

Windows NT
Not set


(thunderbird10 fixed, thunderbird11+ fixed, thunderbird12+ fixed, thunderbird-esr1010+ fixed)

Thunderbird 13.0
Tracking Status
thunderbird10 --- fixed
thunderbird11 + fixed
thunderbird12 + fixed
thunderbird-esr10 10+ fixed


(Reporter: wsmwk, Assigned: Bienvenu)




(Keywords: crash, regression, topcrash, Whiteboard: [GS])

Crash Data


(1 file)

This bug was filed from the Socorro interface and is 
report bp-c88a38fe-8405-4db5-a429-e13cf2120131 .

new top crash for version 10. perhaps exceptionally high crash rate - but can't tell yet if overall crash rate is higher than v9. perhaps standard8 and usul can tell?

most comments (there are not many) mention import from outlook - something I posted about in bug 613439 comment 9

many may be old problems under this new signature. unknown which are related to these crash bugs filed for firefox:
721025 NEW Lots of crashes in GetJSContext
721645 NEW crash in GetContextFromObject @ CrashInJS 
715757 NEW crashes under JS_AbortIfWrongThread, likely from malware or bad extensions
670702 NEW GC minidump findings 

I file this bug to sort out which thunderbird crashes are thunderbird specific and which are core.
bp-c88a38fe-8405-4db5-a429-e13cf2120131 import

0 	mozjs.dll 	CrashInJS 	js/src/jsutil.cpp:86
1 	mozjs.dll 	JS_AbortIfWrongThread 	js/src/jsapi.cpp:6316
2 	mozjs.dll 	mozjs.dll@0x15e46f 	
3 	xul.dll 	XPCCallContext::Init 	js/xpconnect/src/XPCCallContext.cpp:130
4 	xul.dll 	XPCCallContext::XPCCallContext 	js/xpconnect/src/XPCCallContext.cpp:63
5 	xul.dll 	GetContextFromObject 	js/xpconnect/src/XPCWrappedJSClass.cpp:543
6 	xul.dll 	nsXPCWrappedJSClass::DelegatedQueryInterface 	js/xpconnect/src/XPCWrappedJSClass.cpp:660
7 	xul.dll 	nsXPCWrappedJS::QueryInterface 	js/xpconnect/src/XPCWrappedJS.cpp:158
8 	xul.dll 	nsWeakReference::QueryReferent 	objdir-tb/mozilla/xpcom/build/nsWeakReference.cpp:151
9 	xul.dll 	nsQueryReferent::operator 	objdir-tb/mozilla/xpcom/build/nsWeakReference.cpp:88
10 	xul.dll 	nsCOMPtr_base::assign_from_helper 	objdir-tb/mozilla/xpcom/build/nsCOMPtr.cpp:150
11 	xul.dll 	PrefCallback::GetObserver 	modules/libpref/src/nsPrefBranch.h:165
12 	xul.dll 	nsPrefBranch::NotifyObserver 	modules/libpref/src/nsPrefBranch.cpp:660
13 	xul.dll 	pref_DoCallback 	modules/libpref/src/prefapi.cpp:944
14 	xul.dll 	pref_HashPref 	modules/libpref/src/prefapi.cpp:801
15 	xul.dll 	PREF_SetCharPref 	modules/libpref/src/prefapi.cpp:282
16 	xul.dll 	nsPrefBranch::SetCharPref 	modules/libpref/src/nsPrefBranch.cpp:196
17 	xul.dll 	nsPrefBranch::SetComplexValue 	modules/libpref/src/nsPrefBranch.cpp:409
18 	xul.dll 	nsMsgIdentity::SetUnicharAttribute 	mailnews/base/util/nsMsgIdentity.cpp:456
19 	xul.dll 	nsMsgIdentity::SetFullName 	mailnews/base/util/nsMsgIdentity.cpp:173
if outlook import is mucking with the identity on the import thread, this would make sense...previously, this would cause an assertion, but js might have changed to make it fatal.
though I'm not sure who would have a listener for the identity pref changing.
in a sort of random sampling of 12, including short and long up times, every crash includes this on stack

and at least one comment claims to have problems importing now, but had success in prior versions

it's rather shocking to see so many apparent attempts at import - ball park 300-400 users in one day?
Component: General → Import
Keywords: qawantedregression
Product: Thunderbird → MailNews Core
QA Contact: general → import
Summary: crash CrashInJS → crash CrashInJS | nsMsgIdentity::SetFullName | nsOutlookCompose::CreateIdentity
Version: Trunk → 10
Attached patch proposed fixSplinter Review
We had only partly fixed this - we create the initial global identity on the ui thread, but there was still code on the import thread that released the initial identity, and the subsequent calls to CreateIdentity were on the import thread, which made js unhappy. 

With this patch, import works again, and the identity is still freed up at the end, from the UI thread. We should get this fix landed ASAP and onto alpha and beta and the ESR channels, since, w/o it, import from Outlook is broken.
Assignee: nobody → dbienvenu
Attachment #593922 - Flags: review?(mbanner)
Attachment #593922 - Flags: review?(mbanner)
Attachment #593922 - Flags: review+
Attachment #593922 - Flags: approval-comm-beta+
Attachment #593922 - Flags: approval-comm-aurora+
also reported on Geckozone:

Do you plan to fix it in TB10, as it will be really problematic for ESR (enterprise) users?
(In reply to caméléon from comment #5)
> also reported on Geckozone:
> Do you plan to fix it in TB10, as it will be really problematic for ESR
> (enterprise) users?

Yes, we do plan on fixing it in the ESR build.
Attachment #593922 - Flags: approval-comm-esr10+
Checked into trunk:
Closed: 12 years ago
Resolution: --- → FIXED
Attachment #593922 - Flags: approval-comm-release+
l'import des messages fonctionne très bien.
Par contre j'ai un petit souci pour l'import du carnet (des carnets)
TB9 et TB10 importe les contacts en quatre ou huit exemplaires !!!
Alors que TB3 va créer 4 carnets .  Ce qui rend nettement plus facile le tri des doublons. 

traduction avec google
Import messages works fine.
By cons I have a little concern for the import of the book (books)
TB9 TB10 and imports contacts into four or eight copies!
While TB3 will create four books. Making it much easier to sort duplicates.
This got fixed in 10.0.1esr, so updating flags to reflect that the best we can.
You need to log in before you can comment on or make changes to this bug.