Crash in nsObserverService::AddObserver called from PCompositorBridgeChild::SendPLayerTransactionConstructor

RESOLVED WORKSFORME

Status

()

Core
Graphics: Layers
--
critical
RESOLVED WORKSFORME
a year ago
a year ago

People

(Reporter: davidb, Unassigned)

Tracking

({crash, regression})

unspecified
Unspecified
Windows 7
crash, regression
Points:
---

Firefox Tracking Flags

(firefox50 unaffected, firefox51 affected)

Details

(Whiteboard: [gfx-noted])

This bug was filed from the Socorro interface and is 
report bp-63e7baa5-cfd0-4a89-a150-1c8602160815.
=============================================================

More reports here: https://crash-stats.mozilla.com/signature/?product=Firefox&signature=nsObserverService%3A%3AAddObserver
This stack seems bogus to me.  I don't see how PCompositorBridgeChild::SendPLayerTransactionConstructor() could call AddObserver().  Seems likely that gfx is doing something with unallocated memory here.
There are at least two causes of the crash here.

356 out of 412 crashes are from uses of the observer service off the main thread. The assertion is "Using observer service off the main thread!". The ten or so of these crashes I looked at were all from some rapporttanzanex430.dll calling into the observer service from off the main thread. Maybe we can block that DLL or something? Here's an example: bp-89766b30-d496-427c-8700-df1682160816

In the second crash, like the one linked in comment 0, we seem to be reentering the observer service while sending an IPC message. I'm not sure how that can happen, and that doesn't seem like it would by itself cause the crash. Maybe we hit some garbage and are just calling something random? On 51, there are 19 crashes from 2 installations.
See Also: → bug 1295600
I filed bug 1295600 about the observer service crash. It looks like almost all of the Firefox 51 crashes are from the 20160815030201 build, so this may be a new crash.
I'm going to move this over to Graphics, per bkelly's comment 1.
Component: XPCOM → Graphics: Layers
(In reply to Andrew McCreight [:mccr8] from comment #2)
> In the second crash, like the one linked in comment 0, we seem to be
> reentering the observer service while sending an IPC message. I'm not sure
> how that can happen, and that doesn't seem like it would by itself cause the
> crash. Maybe we hit some garbage and are just calling something random? On
> 51, there are 19 crashes from 2 installations.

Or the stack is bogus, like Ben mentioned, and we need to look at things in windbg.  The random addresses in the backtrace lend credence to that theory.
Summary: Crash in nsObserverService::AddObserver → Crash in nsObserverService::AddObserver called from PCompositorBridgeChild::SendPLayerTransactionConstructor
status-firefox50: --- → unaffected
status-firefox51: --- → affected
Keywords: regression
Crash volume for signature 'nsObserverService::AddObserver':
 - nightly (version 51): 19 crashes from 2016-08-01.
 - aurora  (version 50): 0 crashes from 2016-08-01.
 - beta    (version 49): 6 crashes from 2016-08-02.
 - release (version 48): 235 crashes from 2016-07-25.
 - esr     (version 45): 76 crashes from 2016-05-02.

Crash volume on the last weeks (Week N is from 08-22 to 08-28):
            W. N-1  W. N-2  W. N-3
 - nightly      18       1       0
 - aurora        0       0       0
 - beta          5       1       0
 - release      90      68      23
 - esr          18       8       5

Affected platforms: Windows, Mac OS X

Crash rank on the last 7 days:
           Browser     Content   Plugin
 - nightly
 - aurora
 - beta
 - release #262
 - esr     #468
status-firefox48: --- → affected
status-firefox49: --- → affected
status-firefox-esr45: --- → affected
So presumably most of the crashes the bot found in comment 6 really should be reported on bug 1295600? I don't know if there's a good way to stop it from clobbering the flags.

CC'ing dvander for since IPC calling into garbage seems like it's in his wheelhouse.
status-firefox48: affected → ---
status-firefox49: affected → ---
status-firefox-esr45: affected → ---
Whiteboard: [gfx-noted]
And actually it looks like there were no crashes beyond the 20160815030201 build, so it might have been something that got backed out already. This is probably WFM now, with bug 1295600 tracking the dll issue.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → WORKSFORME
Crash volume for signature 'nsObserverService::AddObserver':
 - nightly (version 51): 19 crashes from 2016-08-01.
 - aurora  (version 50): 0 crashes from 2016-08-01.
 - beta    (version 49): 6 crashes from 2016-08-02.
 - release (version 48): 242 crashes from 2016-07-25.
 - esr     (version 45): 81 crashes from 2016-05-02.

Crash volume on the last weeks (Week N is from 08-22 to 08-28):
            W. N-1  W. N-2  W. N-3
 - nightly      18       1       0
 - aurora        0       0       0
 - beta          5       1       0
 - release      90      68      23
 - esr          18       8       5

Affected platforms: Windows, Mac OS X

Crash rank on the last 7 days:
           Browser     Content   Plugin
 - nightly
 - aurora
 - beta
 - release #311
 - esr     #439
status-firefox48: --- → affected
status-firefox49: --- → affected
status-firefox-esr45: --- → affected
Gonna move the crash sig over to bug 1295600.
Crash Signature: [@ nsObserverService::AddObserver]
status-firefox48: affected → ---
status-firefox49: affected → ---
status-firefox-esr45: affected → ---
Blocks: 1320970
No longer blocks: 1320970
You need to log in before you can comment on or make changes to this bug.