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
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 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?
Created attachment 593922 [details] [diff] [review] 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.
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?
(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.
Checked into trunk: http://hg.mozilla.org/comm-central/rev/e63a3641c3d4
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
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.
This got fixed in 10.0.1esr, so updating flags to reflect that the best we can.