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

Status: RESOLVED FIXED

(MailNews Core :: Import, defect)

Description

[Wayne Mery (:wsmwk)]

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.
examples:
bp-c88a38fe-8405-4db5-a429-e13cf2120131 import
bp-6250215b-2197-4a0c-9bb3-475122120201

bp-504537f5-c546-490c-b1ea-e44222120201
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

Comment 1

[David :Bienvenu]

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.

Comment 2

[David :Bienvenu]

though I'm not sure who would have a listener for the identity pref changing.

Comment 3

[Wayne Mery (:wsmwk)]

in a sort of random sampling of 12, including short and long up times, every crash includes this on stack
nsMsgIdentity::SetFullName
nsOutlookCompose::CreateIdentity

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?

Comment 4

[David :Bienvenu]

Attachment: proposed fix

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.

Comment 5

[Vincent (caméléon)]

also reported on Geckozone: http://www.geckozone.org/forum/viewtopic.php?f=4&t=102487

Do you plan to fix it in TB10, as it will be really problematic for ESR (enterprise) users?

Comment 6

[David :Bienvenu]

(In reply to caméléon from comment #5)
> also reported on Geckozone:
> http://www.geckozone.org/forum/viewtopic.php?f=4&t=102487
> 
> 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.

Comment 7

[Mark Banner (:standard8)]

Checked into trunk: http://hg.mozilla.org/comm-central/rev/e63a3641c3d4

Comment 8

[Mark Banner (:standard8)]

Checked into branches:

http://hg.mozilla.org/releases/comm-aurora/rev/4d09c63a01c9
http://hg.mozilla.org/releases/comm-beta/rev/227876aaf64d
http://hg.mozilla.org/releases/comm-release/rev/d77cf4ea22b6
http://hg.mozilla.org/releases/comm-esr10/rev/6e0db5c95022

Comment 9

[J2m06]

bonjour/hello
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.

Comment 10

[Mark Banner (:standard8)]

This got fixed in 10.0.1esr, so updating flags to reflect that the best we can.