Closed Bug 1330955 Opened 3 years ago Closed 3 years ago

Crash in CMapiImp::Login


(Thunderbird :: General, defect, critical)

Windows 10
Not set


(thunderbird50 unaffected, thunderbird51 wontfix, thunderbird52 fixed, thunderbird53 fixed)

Thunderbird 53.0
Tracking Status
thunderbird50 --- unaffected
thunderbird51 --- wontfix
thunderbird52 --- fixed
thunderbird53 --- fixed


(Reporter: wsmwk, Assigned: jorgk)



(4 keywords, Whiteboard: [regression:TB51])

Crash Data


(1 file, 1 obsolete file)

#4 crash for 51.0b1. 

It happens to 51.0b1, 51.0a2, and 52.0a2 (20161222), all *starting* 2016-01-11. [1]
About 1/2 are startup, 1/2 decidedly not. I haven't found any other common factor to startup times, OS versions or addons. 

Caused by a windows update? AV?
bp-1cf1040c-644b-4d38-9b52-209522170111 52.0a2 startup crash
 0 	xul.dll	CMapiImp::Login(unsigned long, wchar_t* const, wchar_t* const, unsigned long, unsigned long*)	C:/builds/moz2_slave/tb-c-aurora-w32-ntly-000000000/build/mailnews/mapi/mapihook/src/msgMapiImp.cpp:161
1 	rpcrt4.dll	Invoke	
2 	rpcrt4.dll	NdrStubCall2	
3 	combase.dll	CStdStubBuffer_Invoke	d:\rs1\onecore\com\combase\ndr\ndrole\stub.cxx:1520
4 	rpcrt4.dll	CStdStubBuffer_Invoke	
5 	combase.dll	ObjectMethodExceptionHandlingAction<<lambda_1ba7c1521bf8e7d0ebd8f0b3c0295667> >(<lambda_1ba7c1521bf8e7d0ebd8f0b3c0295667>, ObjectMethodExceptionHandlingInfo*, ExceptionHandlingResult*, void*)	d:\rs1\onecore\com\combase\dcomrem\excepn.hxx:91
6 	combase.dll	DefaultStubInvoke(bool, IServerCall*, IRpcChannelBuffer*, IRpcStubBuffer*, unsigned long*)	d:\rs1\onecore\com\combase\dcomrem\channelb.cxx:1891
7 	combase.dll	ServerCall::ContextInvoke(tagRPCOLEMESSAGE*, IRpcStubBuffer*, CServerChannel*, tagIPIDEntry*, unsigned long*)	d:\rs1\onecore\com\combase\dcomrem\ctxchnl.cxx:1541
8 	combase.dll	AppInvoke(ServerCall*, CServerChannel*, IRpcStubBuffer*, void*, void*, tagIPIDEntry*, WireLocalThis*)	d:\rs1\onecore\com\combase\dcomrem\channelb.cxx:1604
9 	combase.dll	ComInvokeWithLockAndIPID(ServerCall*, tagIPIDEntry*, bool*)	d:\rs1\onecore\com\combase\dcomrem\channelb.cxx:2722
10 	combase.dll	ThreadWndProc(HWND__*, unsigned int, unsigned int, long)	d:\rs1\onecore\com\combase\dcomrem\chancont.cxx:734 

bp-f0884ad3-b564-4645-9e13-65c062170113 51.0b1 NOT startup
 0 	xul.dll	CMapiImp::Login(unsigned long, wchar_t* const, wchar_t* const, unsigned long, unsigned long*)	C:/builds/moz2_slave/tb-rel-c-beta-w32_bld-00000000/build/mailnews/mapi/mapihook/src/msgMapiImp.cpp:161
Ø 1 	rpcrt4.dll	rpcrt4.dll@0x35a49	
Ø 2 	rpcrt4.dll	rpcrt4.dll@0xb05f0	
3 	ole32.dll	ole32.dll@0x13e7e5	
4 	ole32.dll	ThreadInvoke	
5 	ole32.dll	CStdPSFactoryBuffer_QueryInterface	
6 	ole32.dll	CCtxComChnl::ContextInvoke(tagRPCOLEMESSAGE*, IRpcStubBuffer*, tagIPIDEntry*, unsigned long*)	
7 	ole32.dll	MTAInvoke(tagRPCOLEMESSAGE*, unsigned long, IRpcStubBuffer*, IInternalChannelBuffer*, tagIPIDEntry*, unsigned long*)	d:\w7rtm\com\ole32\com\dcomrem\callctrl.cxx:2097
8 	ole32.dll	STAInvoke(tagRPCOLEMESSAGE*, unsigned long, IRpcStubBuffer*, IInternalChannelBuffer*, void*, tagIPIDEntry*, unsigned long*)	
9 	ole32.dll	HMENU_UserUnmarshal	d:\w7rtm\com\ole32\oleprx32\proxy\transmit.cxx:484
10 	ole32.dll	NdrpCreateNonDelegatedAsyncStub	
11 	ole32.dll	NdrpInitializeStublessVtbl	
12 	ole32.dll	ThreadDispatch(void*)	
13 	ole32.dll	ThreadWndProc(HWND__*, unsigned int, unsigned int, long)	
14 	user32.dll	InternalCallWinProc	
15 	user32.dll	UserCallWinProcCheckWow	
16 	user32.dll	DispatchMessageWorker	
17 	user32.dll	DispatchMessageW	
18 	xul.dll	nsAppShell::ProcessNextNativeEvent(bool)	widget/windows/nsAppShell.cpp:375 

one can say, so far all crashes are windows
could be show stopper for 52.  #1 crash for 51.0b2]1] and 51.0b1 (if you exclude the Mac-messyness). Assuming this will also impact 52 beta, but can't tell via crash-stats

I'm thinking one of these likely caused regression
I can't tell which one because we don't have a regression range for this crash.

Flags: needinfo?(jorgk)
Flags: in-testsuite?
Flags: in-moztrap?
Whiteboard: [regression:TB51]
Looking at
I see a crash in C++ code here:

Clearly there is a hole in the code:


So we're getting the default identity and then dereference it. Hmm, there's an error check, but maybe that passes even of there is no default account.

Patch coming.
Flags: needinfo?(jorgk)
Attached patch 1330955-mapi-crash.patch (v1). (obsolete) — Splinter Review
Assignee: nobody → jorgk
Attachment #8828789 - Flags: review?(rkent)
Oops, didn't notice that there was a |rv = | missing. Aceman pointed it out.
Attachment #8828789 - Attachment is obsolete: true
Attachment #8828789 - Flags: review?(rkent)
Attachment #8828873 - Flags: review?(rkent)
Comment on attachment 8828873 [details] [diff] [review]
1330955-mapi-crash.patch (v2).

I did not actually build and test, but makes sense.
Attachment #8828873 - Flags: review?(rkent) → review+
How's that for a fast turnaround ;-)
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 53.0
Comment on attachment 8828873 [details] [diff] [review]
1330955-mapi-crash.patch (v2).

Let's take it to TB 52 so Wayne can sleep soundly at night ;-) The fix might shift the problem elsewhere, but at least we don't crash at that spot any more.

Thanks Wayne for tirelessly looking at the crash stats. Fixing a bug is good, but fixing a crash is even better since it's obviously the worst bug imaginable!

I looked at most of the 19 reports and didn't see a single one with user comments, so I wonder what's going on there.
Attachment #8828873 - Flags: approval-comm-aurora+
I like these comments:
  This mail program now sucks. like your Browser.
  I'm getting to the point where I hate Thunderbird mail.

Ah well. I think this MAPI stuff is exercising the (right-click) "Send to > Mail recipient". As I said, it will no longer crash there, but I don't know where the problem of not having a default account will shift next.
If the user hasn't set up any mail account in TB, then it hardly can send out anything. We just need to return a proper error to the MAPI caller application.
I would think prior to 51.0b1 the reporters had successfully sent email in this manner. So something must have changed. But I am at a loss to define it.  I am attempting to find a connection.

aceman, how would I go about creating a condition where the profile has no default account?   I cannot reproduce with profile that has no accounts (autoconfig kicks in to set up a new account)

> I like these comments:
Heh. Such comments are not uncommon by frustrated users.  Goes with the territory.  Best to ignore.
Flags: needinfo?(acelists)
(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #13)
> aceman, how would I go about creating a condition where the profile has no
> default account?   I cannot reproduce with profile that has no accounts
> (autoconfig kicks in to set up a new account)
Can that be dismissed? Or try making a RSS or news account only. I think some of these other accounts can't be default, but TB may stop to request creating a mail account.

I know there are many places in code we have to defend as getting the default account throws in JS if there is none.
Flags: needinfo?(acelists)
v.fixed in 52.0b2
Blocks: TB52found
You need to log in before you can comment on or make changes to this bug.