crash in nsXPCWrappedJS::CallMethod via ImportMailThread, accessing nsXPCWrappedJS off-main-thread after nsMsgFolderNotificationService::NotifyFolderDeleted. Mostly importing from Eudora and Outlook

NEW
Unassigned

Status

defect
--
critical
6 years ago
5 months ago

People

(Reporter: wsmwk, Unassigned)

Tracking

(Blocks 1 bug, {crash})

Dependency tree / graph
Bug Flags:
in-testsuite ?
in-moztrap ?

Thunderbird Tracking Flags

(thunderbird38 wontfix, thunderbird39 affected, thunderbird40 affected, thunderbird41 affected, thunderbird_esr24?, thunderbird_esr3840+ affected)

Details

(crash signature)

Attachments

(1 attachment)

Reporter

Description

6 years ago
This bug was filed from the Socorro interface and is 
report bp-4808782d-14a3-4e44-8a4a-17bf62130917.
=============================================================
~#1 crash - if you look at https://crash-stats.mozilla.com/query/?product=Thunderbird&version=Thunderbird%3A24.0&range_value=1&range_unit=weeks&date=09%2F18%2F2013+14%3A00%3A00&query_search=signature&query_type=contains&query=&reason=&release_channels=&build_id=&process_type=any&hang_type=any

0	xul.dll	nsXPCWrappedJS::CallMethod(unsigned short,XPTMethodDescriptor const *,nsXPTCMiniVariant *)	js/xpconnect/src/XPCWrappedJS.cpp
1	xul.dll	PrepareAndDispatch	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp
2	xul.dll	SharedStub	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp
3	xul.dll	nsMsgFolderNotificationService::NotifyFolderDeleted(nsIMsgFolder *)	mailnews/base/src/nsMsgFolderNotificationService.cpp
Reporter

Comment 1

6 years ago
bp-0fbf7d3b-7051-43dc-8dac-e02672130906 tb25.0a2

hg@0 149 /* void notifyFolderDeleted(in nsIMsgFolder aFolder); */
hg@0 150 NS_IMETHODIMP nsMsgFolderNotificationService::NotifyFolderDeleted(nsIMsgFolder *aFolder)
hg@0 151 {
sid1337@162 152 NOTIFY_MSGFOLDER_LISTENERS(folderDeleted, FolderDeleted, (aFolder));
Reporter

Comment 2

6 years ago
Holding solid at #1 crash for TB24. And regression.

Oldest build ID found in 4 months of crashes is TB24 beta 20130814132443. Hard to say via crash-stats how much older the regression really is.

possible reproducible testcase bp-e7700aed-d2f9-419e-81ad-fdad62130920
" It always crashes when I try to import my Apple Mail "
0	XUL	nsXPCWrappedJS::CallMethod(unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*)	js/xpconnect/src/XPCWrappedJS.cpp
1	XUL	PrepareAndDispatch	xpcom/reflect/xptcall/src/md/unix/xptcstubs_x86_64_darwin.cpp
2	XUL	SharedStub	
3	XUL	nsMsgFolderNotificationService::NotifyFolderDeleted(nsIMsgFolder*)	mailnews/base/src/nsMsgFolderNotificationService.cpp
4	XUL	nsMsgDBFolder::RecursiveDelete(bool, nsIMsgWindow*)	mailnews/base/util/nsMsgDBFolder.cpp
5	XUL	nsMsgDBFolder::RecursiveDelete(bool, nsIMsgWindow*)	mailnews/base/util/nsMsgDBFolder.cpp
6	XUL	nsMsgDBFolder::RecursiveDelete(bool, nsIMsgWindow*)	mailnews/base/util/nsMsgDBFolder.cpp
7	XUL	ImportMailThread	mailnews/import/src/nsImportMail.cpp
OS: Windows NT → All
Whiteboard: [regression:tb?? → [regression:tb??]
Reporter

Updated

6 years ago
Blocks: 701533
Reporter

Comment 3

6 years ago
Do we need more than the stack  to move this topcrash to resolution?
Flags: needinfo?
Whiteboard: [regression:tb??]
Flags: needinfo?
Reporter

Comment 4

6 years ago
 GetContextFromObjectOrDefault 
bp-a7d0e794-7a02-476d-bc1f-457422130921
frame 1 is nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS *,unsigned short,XPTMethodDescriptor const *,nsXPTCMiniVariant *)
topcrash is being replaced by more precise keywords per https://bugzilla.mozilla.org/show_bug.cgi?id=927557#c3
Keywords: topcrash-win

Comment 6

5 years ago
In this support thread https://support.mozilla.org/en-US/questions/992982?  The fix was to shorten the path to the local folder that outlook express was imported to.

My assumption is the folder import does not have appropriate code to cope with path > 255 issues, but I have not looked and probably would not know it if I saw it anyway.

Where there is a comment for these they appear to relate to outlook or outlook express import. and lots of french and German.. both of which are fairly verbose languages

Outlook Express uses the folder.dbx file to manage it's folders, outlook uses a similar structure within the PST file so it is quite possible lots of these will appear as the 20 or so characters in the root path to the import folder in Thunderbird just do not exist in these other programs.
Duplicate of this bug: 1141545
Reporter

Comment 8

4 years ago
indeed Most crashes involve importing from Eudora and Outlook

#19 crash for version 31.6.0. 

bp-c98aa9c6-ff81-480e-bb6e-65b042150512
bp-bb0d2f1a-73f6-44ac-a538-d5eef2150420 (kevin)

bp-ac176623-8263-4a66-91ab-04aa82150430 is a rare example with a large stack
0 	xul.dll	nsXPCWrappedJS::CallMethod(unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*)	js/xpconnect/src/XPCWrappedJS.cpp
1 	xul.dll	PrepareAndDispatch	xpcom/reflect/xptcall/md/win32/xptcstubs_x86_64.cpp
2 	xul.dll	SharedStub	xpcom/reflect/xptcall/md/win32/xptcstubs_asm_x86_64.asm
3 	xul.dll	mozJSComponentLoader::ModuleEntry::GetFactory(mozilla::Module const&, mozilla::Module::CIDEntry const&)	js/xpconnect/loader/mozJSComponentLoader.cpp
4 	xul.dll	nsFactoryEntry::GetFactory()	xpcom/components/nsComponentManager.cpp
5 	xul.dll	nsComponentManagerImpl::CreateInstanceByContractID(char const*, nsISupports*, nsID const&, void**)	xpcom/components/nsComponentManager.cpp
6 	xul.dll	CallCreateInstance(char const*, nsISupports*, nsID const&, void**)	xpcom/glue/nsComponentManagerUtils.cpp
7 	xul.dll	nsCreateInstanceByContractID::operator()(nsID const&, void**)	xpcom/glue/nsComponentManagerUtils.cpp
8 	xul.dll	nsCOMPtr_base::assign_from_helper(nsCOMPtr_helper const&, nsID const&)	xpcom/glue/nsCOMPtr.cpp
9 	xul.dll	nsMsgCompFields::nsMsgCompFields()	c:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/mailnews/compose/src/nsMsgCompFields.cpp:63
10 	xul.dll	nsMsgCompFieldsConstructor	c:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/mailnews/build/nsMailModule.cpp:552
11 	xul.dll	nsComponentManagerImpl::CreateInstance(nsID const&, nsISupports*, nsID const&, void**)	xpcom/components/nsComponentManager.cpp
12 	xul.dll	CallCreateInstance(nsID const&, nsISupports*, nsID const&, void**)	xpcom/glue/nsComponentManagerUtils.cpp
13 	xul.dll	nsOutlookCompose::CreateComponents()	c:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/mailnews/import/outlook/src/nsOutlookCompose.cpp:246
14 	xul.dll	nsOutlookCompose::ComposeTheMessage(int, CMapiMessage&, nsIFile**)	c:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/mailnews/import/outlook/src/nsOutlookCompose.cpp:259
15 	xul.dll	nsOutlookCompose::ProcessMessage(int, CMapiMessage&, nsIOutputStream*)	c:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/mailnews/import/outlook/src/nsOutlookCompose.cpp:462
16 	xul.dll	nsOutlookMail::ImportMessage(IMessage*, nsIOutputStream*, int)	c:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/mailnews/import/outlook/src/nsOutlookMail.cpp:465
17 	xul.dll	nsOutlookMail::ImportMailbox(unsigned int*, bool*, int, wchar_t const*, nsIMsgFolder*, int*)	c:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/mailnews/import/outlook/src/nsOutlookMail.cpp:424
18 	xul.dll	ImportOutlookMailImpl::ImportMailbox(nsIImportMailboxDescriptor*, nsIMsgFolder*, wchar_t**, wchar_t**, bool*)	c:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/mailnews/import/outlook/src/nsOutlookImport.cpp:423
19 	xul.dll	ImportMailThread	c:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/mailnews/import/src/nsImportMail.cpp:835
Summary: crash in nsXPCWrappedJS::CallMethod(unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) accessing nsXPCWrappedJS off-main-thread after nsMsgFolderNotificationService::NotifyFolderDeleted → crash in nsXPCWrappedJS::CallMethod(unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) accessing nsXPCWrappedJS off-main-thread after nsMsgFolderNotificationService::NotifyFolderDeleted. Mostly importing from Eudora and Outlook
XPCOM written by JavaScript has to run on Gecko's main thread.  So both crashes may be same reason that JS based XPCOM tries to run on worker thread for import.

Also, nsOutlookCompose seems to run it on worker thread, so does anyone override "@mozilla.org/messenger/structuredheaders;1" XPCOM that used by nsMsgCompFields?


Wayne, since TB38 will replace MIME parser with JSMIME, we should test outlook and eudora import works correctly on TB38 before released.
Ah, comment #9 seems to be TB38.  outlook and eudora import may not work correctly since replacing with JSMIME.  We should test it.
Reporter

Comment 12

4 years ago
(In reply to Makoto Kato (:m_kato) from comment #10)
> XPCOM written by JavaScript has to run on Gecko's main thread.  So both
> crashes may be same reason that JS based XPCOM tries to run on worker thread
> for import.
> 
> Also, nsOutlookCompose seems to run it on worker thread, so does anyone
> override "@mozilla.org/messenger/structuredheaders;1" XPCOM that used by
> nsMsgCompFields?
> 
> 
> Wayne, since TB38 will replace MIME parser with JSMIME, we should test
> outlook and eudora import works correctly on TB38 before released.

I haven't tested yet. Perhaps someone else can?


Reminder, crash signature existed prior to version 38 as #25 crash, not #1 as it is in version 38. So bug 858337 (implement header parsing in JSMime) or something else certainly could have just made things worse.

Note also, having this appear in a release suggests we lack enough tests in this area.
Component: Backend → Import
Flags: needinfo?(mozilla)
Flags: needinfo?(anjeyelf)
Flags: in-testsuite?
Flags: in-moztrap?

Comment 13

4 years ago
I tried a Eudora Import. Before I did, I needed to apply this registry change, so TB could find the Eudoradata. Of course I do NOT have Eudora installed but I have some old Eudora mailboxes:
=== Registry file, adjust file location as required ===
Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Qualcomm\Eudora\CommandLine]
"Current"="Anything H:\\SCRATCH\\Eudoradata Anything"
===

The import crashes in TB 38 and the daily which I compiled myself. The latter gives this:

Hit MOZ_CRASH(nsMsgBrkMBoxStore not thread-safe) at h:/mozilla-source/comm-central/mailnews/local/src/nsMsgBrkMBoxStore.cpp:49
#01: nsMsgIncomingServer::GetMsgStore (h:\mozilla-source\comm-central\mailnews\base\util\nsmsgincomingserver.cpp:958)
#02: nsMsgDBFolder::GetMsgStore (h:\mozilla-source\comm-central\mailnews\base\util\nsmsgdbfolder.cpp:743)
#03: nsEudoraMailbox::ImportMailboxUsingTOC (h:\mozilla-source\comm-central\mailnews\import\eudora\src\nseudoramailbox.cpp:379)
#04: nsEudoraMailbox::ImportMailbox (h:\mozilla-source\comm-central\mailnews\import\eudora\src\nseudoramailbox.cpp:236)
#05: ImportEudoraMailImpl::ImportMailbox (h:\mozilla-source\comm-central\mailnews\import\eudora\src\nseudoraimport.cpp:542)
#06: ImportMailThread (h:\mozilla-source\comm-central\mailnews\import\src\nsimportmail.cpp:836)
#07: _PR_NativeRunThread (h:\mozilla-source\comm-central\mozilla\nsprpub\pr\src\threads\combined\pruthr.c:397)
#08: pr_root (h:\mozilla-source\comm-central\mozilla\nsprpub\pr\src\md\windows\w95thred.c:90)
#09: _get_flsindex[MSVCR120 +0x2c01d]
#10: _get_flsindex[MSVCR120 +0x2c001]
#11: BaseThreadInitThunk[kernel32 +0x1337a]
#12: RtlInitializeExceptionChain[ntdll +0x392e2]
#13: RtlInitializeExceptionChain[ntdll +0x392b5]
Flags: needinfo?(mozilla)

Comment 14

4 years ago
With this test mailbox, the crash looks a little different:

Hit MOZ_CRASH(nsMsgBrkMBoxStore not thread-safe) at h:/mozilla-source/comm-central/mailnews/local/src/nsMsgBrkMBoxStore.cpp:49
#01: nsMsgIncomingServer::GetMsgStore (h:\mozilla-source\comm-central\mailnews\base\util\nsmsgincomingserver.cpp:958)
#02: nsMsgDBFolder::GetMsgStore (h:\mozilla-source\comm-central\mailnews\base\util\nsmsgdbfolder.cpp:743)
#03: nsEudoraMailbox::ImportMailbox (h:\mozilla-source\comm-central\mailnews\import\eudora\src\nseudoramailbox.cpp:288)
#04: ImportEudoraMailImpl::ImportMailbox (h:\mozilla-source\comm-central\mailnews\import\eudora\src\nseudoraimport.cpp:542)
#05: ImportMailThread (h:\mozilla-source\comm-central\mailnews\import\src\nsimportmail.cpp:836)
#06: _PR_NativeRunThread (h:\mozilla-source\comm-central\mozilla\nsprpub\pr\src\threads\combined\pruthr.c:397)
#07: pr_root (h:\mozilla-source\comm-central\mozilla\nsprpub\pr\src\md\windows\w95thred.c:90)
#08: _get_flsindex[MSVCR120 +0x2c01d]
#09: _get_flsindex[MSVCR120 +0x2c001]
#10: BaseThreadInitThunk[kernel32 +0x1337a]
#11: RtlInitializeExceptionChain[ntdll +0x392e2]
#12: RtlInitializeExceptionChain[ntdll +0x392b5]

Comment 15

4 years ago
Just as a general note regarding Eudora import:
I use Thunderbird 1.5 (yes, one point five) to do it, and I pre-process the data with "Eudora Rescue":
http://kb.mozillazine.org/Importing_from_Eudora_(Thunderbird)#Importing_Eudora_Mail_with_Eudora_Rescue
IMHO we should remove Eudora import from Thunderbird completely because Eudora has been dead for about 10 years now and the import was never any good. Outlook is of course a different story.

Comment 16

4 years ago
(In reply to Jorg K from comment #15)

> IMHO we should remove Eudora import from Thunderbird completely because
> Eudora has been dead for about 10 years now and the import was never any
> good. Outlook is of course a different story.

I agree wholeheartedly.  Almost everyone left n the Eudora camp want to spent significant time in support forums complaining that Thunderbird does not store their attachments in a separate folder,  Thunderbird messes their mailing lists on import and their "Eudora way" of doing things does not work with Thunderbird.  Remove the import and we can add to the relevant knowledgebase article the last version with import in it.

Comment 17

4 years ago
Moving on to Outlook import. I fired up my old Vista machine which has Outlook 2003 installed.
TB 38 crashes when attempting an Outlook import. This is what the daily version gives before it also crashes:

Hit MOZ_CRASH(nsMsgBrkMBoxStore not thread-safe) at h:/mozilla-source/comm-central/mailnews/local/src/nsMsgBrkMBoxStore.cpp:49
#01: NS_LogInit[xul +0x4c7a1a]
#02: NS_LogInit[xul +0x4aeb08]
#03: NS_LogInit[xul +0x6f47b0]
#04: NS_LogInit[xul +0x6f2546]
#05: NS_LogInit[xul +0x6c4a2e]
#06: PR_MkDir[nss3 +0x288308]
#07: PR_MkDir[nss3 +0x2756bf]
#08: _get_flsindex[MSVCR120 +0x2c01d]
#09: _get_flsindex[MSVCR120 +0x2c001]
#10: BaseThreadInitThunk[kernel32 +0x4d0e9]
#11: RtlInitializeExceptionChain[ntdll +0x419bb]
#12: RtlInitializeExceptionChain[ntdll +0x4198e]

In conclusion: Import is well an truly busted. However, this is new and really doesn't belong in this bug which was raised on 2013. Maybe we should create two new bugs:
1) Eudora import busted, remove from system.
2) Outlook import busted, let's fix it.

Most likely Outlook Express import is also busted, I'd have to fire up an old XP machine to try it. Outlook Express died with Windows XP in April 2014. Perhaps there are still some people who want to get off XP and move to Thunderbird on another platform.

Comment 18

4 years ago
Moving on to Outlook Express (Windows XP) import: That worked like a charm with TB38, I imported a few mailboxes on an old XP machine. Sorry about the doomsaying from my previous comment ;-)
Reporter

Comment 19

4 years ago
Crash comments that mention outlook cite:
2000
2003
2007
2010

Can anyone test those for jorgk?

Comment 20

4 years ago
I have an old Outlook 2000 somewhere, but what's the point?
We know it crashes straight away. Wayne, would you like the raise the bugs as detailed in comment #17:
1) Eudora import busted, remove from system.
2) Outlook import busted, let's fix it.

The crash that is described in this bug is now obscured by the fact that the import doesn't work at all any more since it crashes straight away and consistently in the same way for Eudora and Outlook.
Crash Signature: [@ nsXPCWrappedJS::CallMethod(unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*)] → [@ nsXPCWrappedJS::CallMethod(unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*)] [@ nsXPCWrappedJS::AddRef()] [@ mozilla::dom::workers::GetCurrentThreadJSContext()]

Updated

4 years ago
Blocks: 1175055

Comment 21

4 years ago
Wayne, I've added a new bug 1175055 and I'm getting the hell out of this one.
Reporter

Updated

4 years ago
Blocks: 1175168
Reporter

Comment 22

4 years ago
Do we need a separate bug to cover the path issue, coment 6?

Comment 23

4 years ago
Yes, if the "path issue" is an issue. Comment #6 says: "... but I have not looked ...".

Comment 24

4 years ago
(In reply to Jorg K from comment #23)
> Yes, if the "path issue" is an issue. Comment #6 says: "... but I have not
> looked ...".

I would not recognise it if I did.  But I think the limit will be there by being absent. Windows has the 256 character limit on a path.  So the add for the folder works fine, but when the O/s Is asked for that path it returns a truncated version is my guess.  It may even return a truncated path in the add folder function.

elcamelion

Comment 25

4 years ago
Anje,Vincent,  Have you seen anything regarding path lengths in support?
Flags: needinfo?(el.cameleon.1)

Updated

4 years ago
Blocks: 1176748
The plan is to "fix" this in 38.1.0 by disabling import, and get import working in a subsequent release.
so let's block 38.2.0 on this.

Updated

4 years ago
Crash Signature: [@ nsXPCWrappedJS::CallMethod(unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*)] [@ nsXPCWrappedJS::AddRef()] [@ mozilla::dom::workers::GetCurrentThreadJSContext()] → [@ nsXPCWrappedJS::CallMethod(unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*)] [@ nsXPCWrappedJS::AddRef()] [@ mozilla::dom::workers::GetCurrentThreadJSContext()] [@ nsXPCWrappedJS::CallMethod] [@ nsXPCWrappedJS::AddRef] [@ mozilla::d…
Flags: needinfo?(el.cameleon.1)
Reporter

Comment 28

10 months ago
Import for outlook is reenabled in version 60
Reporter

Comment 29

5 months ago
Import crash nsXPCWrappedJS::CallMethod bp-16cb8353-5fbf-4a16-8993-27d8c0190103 65.0b1
 0 	xul.dll	nsXPCWrappedJS::CallMethod(unsigned short, nsXPTMethodInfo const*, nsXPTCMiniVariant*)	js/xpconnect/src/XPCWrappedJS.cpp:615
1 	xul.dll	static nsresult PrepareAndDispatch(class nsXPTCStubBase*, unsigned int, unsigned int*, unsigned int*)	xpcom/reflect/xptcall/md/win32/xptcstubs.cpp:88
2 	xul.dll	static void SharedStub()	xpcom/reflect/xptcall/md/win32/xptcstubs.cpp:110
3 	xul.dll	nsMsgFolderNotificationService::NotifyFolderDeleted(nsIMsgFolder*)	comm/mailnews/base/src/nsMsgFolderNotificationService.cpp:149
4 	xul.dll	nsMsgDBFolder::RecursiveDelete(bool, nsIMsgWindow*)	comm/mailnews/base/util/nsMsgDBFolder.cpp:3755
5 	xul.dll	static void ImportMailThread(void*)	comm/mailnews/import/src/nsImportMail.cpp:829
6 	nss3.dll	_PR_NativeRunThread	nsprpub/pr/src/threads/combined/pruthr.c:397
7 	nss3.dll	static unsigned int pr_root(void*)	nsprpub/pr/src/md/windows/w95thred.c:137
8 	ucrtbase.dll	_o____lc_collate_cp_func	
9 	kernel32.dll	BaseThreadInitThunk	
10 	mozglue.dll	static void patched_BaseThreadInitThunk(int, void*, void*)	mozglue/build/WindowsDllBlocklist.cpp:715 

Another example is bp-2507222d-464a-46b6-84ec-1fa620181229 60.3.3
 0 	xul.dll	nsXPCWrappedJS::CallMethod(unsigned short, nsXPTMethodInfo const*, nsXPTCMiniVariant*)	js/xpconnect/src/XPCWrappedJS.cpp:610
1 	xul.dll	PrepareAndDispatch	xpcom/reflect/xptcall/md/win32/xptcstubs.cpp:85
2 	xul.dll	mozilla::detail::nsTStringRepr<char>::Equals(mozilla::detail::nsTStringRepr<char> const&)	xpcom/string/nsTSubstring.cpp:864
3 	xul.dll	NS_TableDrivenQI(void*, nsID const&, void**, QITableEntry const*)	xpcom/base/nsISupportsImpl.cpp:23
4 	xul.dll	nsComponentManagerImpl::GetServiceByContractID(char const*, nsID const&, void**)	xpcom/components/nsComponentManager.cpp:1393
5 	xul.dll	nsMsgDBFolder::RecursiveDelete(bool, nsIMsgWindow*)	comm/mailnews/base/util/nsMsgDBFolder.cpp:3731
6 	xul.dll	nsMsgDBFolder::RecursiveDelete(bool, nsIMsgWindow*)	comm/mailnews/base/util/nsMsgDBFolder.cpp:3709
7 	xul.dll	nsMsgDBFolder::RecursiveDelete(bool, nsIMsgWindow*)	comm/mailnews/base/util/nsMsgDBFolder.cpp:3709
8 	xul.dll	nsMsgDBFolder::RecursiveDelete(bool, nsIMsgWindow*)	comm/mailnews/base/util/nsMsgDBFolder.cpp:3709
9 	xul.dll	nsMsgDBFolder::RecursiveDelete(bool, nsIMsgWindow*)	comm/mailnews/base/util/nsMsgDBFolder.cpp:3709
10 	xul.dll	ImportMailThread	comm/mailnews/import/src/nsImportMail.cpp:830 

bp-7c02ab14-4e99-4f31-99c4-6fd620181221 has similar stack with ImportMailThread, but oddly doesn't mention import
Crash Signature: [@ nsXPCWrappedJS::CallMethod(unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*)] [@ nsXPCWrappedJS::AddRef()] [@ mozilla::dom::workers::GetCurrentThreadJSContext()] [@ nsXPCWrappedJS::CallMethod] [@ nsXPCWrappedJS::AddRef] [@ mozilla::d… → [@ nsXPCWrappedJS::CallMethod] [@ nsXPCWrappedJS::AddRef]
Flags: needinfo?(anjeyelf)
Summary: crash in nsXPCWrappedJS::CallMethod(unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) accessing nsXPCWrappedJS off-main-thread after nsMsgFolderNotificationService::NotifyFolderDeleted. Mostly importing from Eudora and Outlook → crash in nsXPCWrappedJS::CallMethod via ImportMailThread, accessing nsXPCWrappedJS off-main-thread after nsMsgFolderNotificationService::NotifyFolderDeleted. Mostly importing from Eudora and Outlook
You need to log in before you can comment on or make changes to this bug.