Crash in nsMsgCompose::CloseWindow



a year ago
16 days ago


(Reporter: wsmwk, Unassigned)


(Blocks: 1 bug, {crash})

Mac OS X

Firefox Tracking Flags

(Not tracked)


(crash signature)



a year ago
~20% of crashes are Mac, which is pretty high for Mac

This bug was filed from the Socorro interface and is 
report bp-ba56e1db-d50f-4f49-a6ef-c330d0170903.
0 	XUL	nsMsgCompose::CloseWindow()	/builds/slave/tb-rel-c-esr52-m64_bld-0000000/build/mailnews/compose/src/nsMsgCompose.cpp:1565
1 	XUL	nsMsgComposeSendListener::OnStopCopy(nsresult)	/builds/slave/tb-rel-c-esr52-m64_bld-0000000/build/mailnews/compose/src/nsMsgCompose.cpp:3923
2 	XUL	nsMsgComposeAndSend::MaybePerformSecondFCC(nsresult)	/builds/slave/tb-rel-c-esr52-m64_bld-0000000/build/mailnews/compose/src/nsMsgSend.cpp:3965
3 	XUL	nsMsgComposeAndSend::OnStopOperation(nsresult)	/builds/slave/tb-rel-c-esr52-m64_bld-0000000/build/mailnews/compose/src/nsMsgSend.cpp:3924
4 	XUL	nsMsgFilterAfterTheFact::AdvanceToNextFolder()	/builds/slave/tb-rel-c-esr52-m64_bld-0000000/build/mailnews/base/search/src/nsMsgFilterService.cpp:362
5 	XUL	nsMsgApplyFiltersToMessages::RunNextFilter()	/builds/slave/tb-rel-c-esr52-m64_bld-0000000/build/mailnews/base/search/src/nsMsgFilterService.cpp:1102
6 	XUL	nsMsgFilterAfterTheFact::AdvanceToNextFolder()	/builds/slave/tb-rel-c-esr52-m64_bld-0000000/build/mailnews/base/search/src/nsMsgFilterService.cpp:464
7 	XUL	nsMsgFilterService::ApplyFilters(int, nsIArray*, nsIMsgFolder*, nsIMsgWindow*, nsIMsgOperationListener*)	/builds/slave/tb-rel-c-esr52-m64_bld-0000000/build/mailnews/base/search/src/nsMsgFilterService.cpp:1129
8 	XUL	nsMsgComposeAndSend::FilterSentMessage()	/builds/slave/tb-rel-c-esr52-m64_bld-0000000/build/mailnews/compose/src/nsMsgSend.cpp:3894
9 	XUL	nsMsgComposeAndSend::NotifyListenerOnStopCopy(nsresult)	/builds/slave/tb-rel-c-esr52-m64_bld-0000000/build/mailnews/compose/src/nsMsgSend.cpp:3853
10 	XUL	CopyListener::OnStopCopy(nsresult)	/builds/slave/tb-rel-c-esr52-m64_bld-0000000/build/mailnews/compose/src/nsMsgCopy.cpp:116
11 	XUL	nsMsgCopyService::ClearRequest(nsCopyRequest*, nsresult)	/builds/slave/tb-rel-c-esr52-m64_bld-0000000/build/mailnews/base/src/nsMsgCopyService.cpp:210
12 	XUL	nsMsgCopyService::NotifyCompletion(nsISupports*, nsIMsgFolder*, nsresult)	/builds/slave/tb-rel-c-esr52-m64_bld-0000000/build/mailnews/base/src/nsMsgCopyService.cpp:695
13 	XUL	nsMsgLocalMailFolder::OnCopyCompleted(nsISupports*, bool)	/builds/slave/tb-rel-c-esr52-m64_bld-0000000/build/mailnews/local/src/nsLocalMailFolder.cpp:1483

Comment 1

a year ago
bp-0b4db255-2d44-43cf-83ec-95f610170902 writes "I cannot send out mails and messages".

But almost none of the crash reporters have sent more than one crash report.

Comment 2

a year ago
Hmm, this is the code that crashes:
NS_IMETHODIMP nsMsgCompose::CloseWindow(void)
  if (m_baseWindow)
    nsIBaseWindow * window = m_baseWindow;
    m_baseWindow = nullptr;
    rv = window->Destroy(); <=== 1565

Hard to see why that would crash although I don't understand the pointer acrobatics here. Nulling out m_baseWindow might destroy the window if no reference is left. Strange. Kent, do you have a better understanding?

Why not just:
rv = m_baseWindow->Destroy();
m_baseWindow = nullptr;
Flags: needinfo?(rkent)
The only reason I can think of for this code is doing what they also suggested for m_editor, making sure that any other uses in nsMsgCompose are not used. But this makes no sense, because this location is the only current use in nsMsgCompose of m_baseWindow.

Looking at the crash report, it looks to me like the value of window ("Crash Address") is 0xffffffffe5e5e5f9. I'll guess that the value represents destroyed memory, but an offset into it. What could be destroyed? My best guess would be the nsMsgCompose object itself, with the difference between 0xffffffffe5e5e5f9 and 0xffffffffe5e5e5e5 being the location of m_baseWindow in "this". But it is not at all clear how that could happen.
Flags: needinfo?(rkent)

Comment 4

10 months ago
Mac user in bp-5a142ebf-b394-49ad-86d7-663130180106 writes "the message is well sent but it is impossible for thunderbird to copy the message in the "sent" folder. Actually I tend to think that the "sent" folder is not named "sent" but something like "sent messages" or "messages envoyés" as I use a french version of my mailbox (this is a outlook web application hosted and managed by OVH). This doesn't occur with another mail software. This is a bit of a pity because I lose trace of my sent messages"

I wonder if some users don't crash, but instead experience hangs like bug 1381485 (which has a stacktrace)
Component: General → Composition
Product: Thunderbird → MailNews Core

Comment 5

16 days ago
Crash rate is up 30% since early November, but unclear why. Mac/Windows ratio is the same, about 50-50.

I suspect for Mac this is also related Bug 1381485 - Hangs frequently while sending imap mail while copying message to imap Sent folder on Mac. No problem if Sent is set to local folder. deadlock on CGLClearDrawable?


16 days ago
Blocks: 1381485
You need to log in before you can comment on or make changes to this bug.