1404623 - Crash in CStdMarshal::DisconnectSrvIPIDs

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect, P2)

Description

[[:philipp]]

This bug was filed from the Socorro interface and is 
report bp-f1813876-1e55-4055-ae19-35db20170930.
=============================================================
Crashing Thread (54)
Frame 	Module 	Signature 	Source
0 	combase.dll 	CStdMarshal::DisconnectSrvIPIDs(unsigned long) 	d:\rs1\onecore\com\combase\dcomrem\marshal.cxx:5090
1 		@0x2ff 	
2 	combase.dll 	CStdMarshal::Disconnect(unsigned long) 	d:\rs1\onecore\com\combase\dcomrem\marshal.cxx:4282
3 	combase.dll 	CRemoteUnknown::RemReleaseWorker(unsigned short, tagREMINTERFACEREF* const, int) 	d:\rs1\onecore\com\combase\dcomrem\remoteu.cxx:1189
4 	rpcrt4.dll 	Invoke 	
5 	combase.dll 	combase.dll@0x1e21df 	
6 	rpcrt4.dll 	Ndr64StubWorker(void*, void*, _RPC_MESSAGE*, _MIDL_SERVER_INFO_*, long (*const*)(void), _MIDL_SYNTAX_INFO*, unsigned long*) 	
7 	rpcrt4.dll 	NdrStubCall3 	
8 	combase.dll 	CStdStubBuffer_Invoke 	d:\rs1\onecore\com\combase\ndr\ndrole\stub.cxx:1461
9 	combase.dll 	ObjectMethodExceptionHandlingAction<<lambda_76d9e92c799d246a4afbe64a2bf5673d> >(<lambda_76d9e92c799d246a4afbe64a2bf5673d>, ObjectMethodExceptionHandlingInfo*, ExceptionHandlingResult*, void*) 	d:\rs1\onecore\com\combase\dcomrem\excepn.hxx:91
10 	combase.dll 	DefaultStubInvoke(bool, IServerCall*, IRpcChannelBuffer*, IRpcStubBuffer*, unsigned long*) 	d:\rs1\onecore\com\combase\dcomrem\channelb.cxx:1891
11 	combase.dll 	ServerCall::ContextInvoke(tagRPCOLEMESSAGE*, IRpcStubBuffer*, CServerChannel*, tagIPIDEntry*, unsigned long*) 	d:\rs1\onecore\com\combase\dcomrem\ctxchnl.cxx:1541
12 	combase.dll 	AppInvoke(ServerCall*, CServerChannel*, IRpcStubBuffer*, void*, void*, tagIPIDEntry*, WireLocalThis*) 	d:\rs1\onecore\com\combase\dcomrem\channelb.cxx:1616
13 	combase.dll 	ComInvokeWithLockAndIPID(ServerCall*, tagIPIDEntry*, bool*) 	d:\rs1\onecore\com\combase\dcomrem\channelb.cxx:2722
14 	combase.dll 	ThreadInvoke(_RPC_MESSAGE*) 	d:\rs1\onecore\com\combase\dcomrem\channelb.cxx:7082
15 	rpcrt4.dll 	DispatchToStubInCNoAvrf 	
16 	rpcrt4.dll 	RPC_INTERFACE::DispatchToStubWorker(_RPC_MESSAGE*, unsigned int, int, long*) 	
17 	rpcrt4.dll 	RPC_INTERFACE::DispatchToStubWithObject(_RPC_MESSAGE*, RPC_UUID*, unsigned int, int, long*, RPCP_INTERFACE_GROUP*) 	
18 	rpcrt4.dll 	LRPC_SCALL::DispatchRequest(int*) 	
19 	rpcrt4.dll 	LRPC_SCALL::HandleRequest(_PORT_MESSAGE*, _PORT_MESSAGE*, void*, unsigned __int64, RPCP_ALPC_HANDLE_ATTR*) 	
20 	rpcrt4.dll 	LRPC_ADDRESS::HandleRequest(_PORT_MESSAGE*, RPCP_ALPC_MESSAGE_ATTRIBUTES*, _PORT_MESSAGE*, int) 	
21 	rpcrt4.dll 	LRPC_ADDRESS::ProcessIO(void*) 	
22 	rpcrt4.dll 	LrpcIoComplete(_TP_CALLBACK_INSTANCE*, void*, _TP_ALPC*, void*) 	
23 	ntdll.dll 	TppAlpcpExecuteCallback 	
24 	ntdll.dll 	TppWorkerThread 	
25 	kernel32.dll 	BaseThreadInitThunk 	
26 	ntdll.dll 	RtlUserThreadStart

this crash signature is jumping up during 57.0b - i'm unsure where to file it, but the correlations in regards to accessibility may indicate that perhaps it's related to the e10s-a11y work?

Correlations for Firefox Beta
(100.0% in signature vs 06.37% overall) reason = EXCEPTION_ACCESS_VIOLATION_READ
(100.0% in signature vs 18.37% overall) accessibility = Active
(100.0% in signature vs 02.32% overall) platform_version = 10.0.14393
(61.70% in signature vs 00.60% overall) Module "uiautomationcore.dll" = true
(31.91% in signature vs 00.07% overall) Module "UIAutomationCore.DLL" = true

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

Wild-ptr (UAF??) READ crashes...

Comment 2

[David Bolter [:davidb] (NeedInfo me for attention)]

Accessibility is definitely causing this signature to spike, but it has been around for a while (with and without a11y active). Do we have any previously filed sec bugs about it?

Comment 3

[Wennie]

Hi Alexander:

I have assigned these security bugs to you to reassign them to appropriate developers in your team to investigate and fix them.

Thanks!

Wennie

Comment 4

[alexander :surkov (:asurkov)]

Aaron would you mind to look at these COM stuff please?

Comment 5

[(No longer employed by Mozilla) Aaron Klotz]

We have discussed this but there isn't anything actionable from this, unfortunately.

Comment 6

[Randell Jesup [:jesup] (needinfo me)]

happening more or less forever, the concern is that it's spiked pretty dramatically recently in 57beta, so something we did provoked it.  Not amenable to regression-range checking though unless the spike started in mid-beta (nightly has too low a rate to help with regression-range).

Stacks look less than useful, though maybe there's a good one somewhere there

Comment 7

[Frederik Braun [:freddy]]

The correlations also mention a strong correlation with Windows 10 (96.88), which could be another driver begind the spike. Given, how people get new devices over the holidays (or find the tech-savvy relative to do the updates for them :)))

Comment 8

[Frederik Braun [:freddy]]

Crash rate is going down. Anyone got an idea why that might be the case?

Comment 9

[James Teh [:Jamie]]

I don't know exactly, but it here are two possibilities:
1. Bug 1434822, which means that we clean up remote references to our objects when the object dies rather than letting COM do it when all remote clients disconnect.
2. Bug 1433046, which provided several "correctness" fixes concerning handling of references.

Comment 10

[David Bolter [:davidb] (NeedInfo me for attention)]

Aaron can you think of any diagnostics that would help us learn more from these crashes?
Alex are you out of ideas?

Comment 11

[alexander :surkov (:asurkov)]

(In reply to David Bolter [:davidb] (NeedInfo me for attention) from comment #10)
> Alex are you out of ideas?

The stack is not helpful, looks MSCOMish and too random with me to be helpful here. On the other side the crash ratio goes down over last months, so it's probably of lower priority now than it was used to be.

Comment 12

[(No longer employed by Mozilla) Aaron Klotz]

Unfortunately without being able to debug a live machine, I doubt that there is much else we can do here.

Comment 13

[Pascal Chevrel:pascalc (PTO until April 26)]

low volume and stalled, wontif for our release in flight.

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last months and this bug has priority 'P2'/severity 'critical'.
:Jamie, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 15

[James Teh [:Jamie]]

While comment 6 suggests that not all crashes with this signature are related to e10s a11y (Firefox 57+), the spike discussed in this bug is. That should be fixed by Cache the World, which is enabled by default in Firefox 113.

Comment 16

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

Since the bug is closed, the stalled keyword is now meaningless.
For more information, please visit BugBot documentation.