1499855 - Crash in mozilla::dom::GetPerInterfaceObjectHandle

Status: RESOLVED INCOMPLETE

(Core :: DOM: Core & HTML, defect, P3)

Description

[Marcia Knous [:marcia]]

This bug was filed from the Socorro interface and is
report bp-61717e90-297c-4dbf-af65-a76800181009.
=============================================================

Seen while looking at nightly crash stats: https://bit.ly/2S2u7XY. Windows and Mac crashes started using 20181009100040. Most of the URLs appear to be videos. 

Possible regression range based on Build ID: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fb8edc9e0e00097813febdb64a64c82666c812be&tochange=6f8701d1be0ccf42a8e22bfce6f40056a4f58a1b

Top 10 frames of crashing thread:

0 xul.dll mozilla::dom::GetPerInterfaceObjectHandle dom/bindings/BindingUtils.cpp:4198
1 xul.dll mozilla::dom::MouseEvent_Binding::Wrap dom/bindings/MouseEventBinding.cpp:1860
2 xul.dll mozilla::dom::MouseEvent::WrapObjectInternal dom/events/MouseEvent.h:29
3 xul.dll mozilla::dom::EventListener::HandleEvent dom/bindings/EventListenerBinding.cpp:30
4 xul.dll nsresult mozilla::EventListenerManager::HandleEventSubType dom/events/EventListenerManager.cpp:1102
5 xul.dll void mozilla::EventTargetChainItem::HandleEvent dom/events/EventDispatcher.cpp:424
6 xul.dll static void mozilla::EventTargetChainItem::HandleEventTargetChain dom/events/EventDispatcher.cpp:677
7 xul.dll mozilla::EventDispatcher::Dispatch dom/events/EventDispatcher.cpp:1156
8 xul.dll nsresult mozilla::PresShell::HandleEventInternal layout/base/PresShell.cpp:7678
9 xul.dll mozilla::PresShell::HandleEvent layout/base/PresShell.cpp:7288

=============================================================

Comment 1

[Marcia Knous [:marcia]]

Crashes continued while 64 was in nightly, but in fairly small volume (highest per day was 6-7 crashes). So far no crashes have been seen in 65.

Comment 2

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

Many crashes (in 60.*/esr60) with UAF/wildptr/EXEC/priv-instruction failures).  In 64 we get an assertion or maybe null-deref:
MOZ_CRASH(Looks like bug 1488480/1405521, with aCreator failing to create Document.prototype)

In 63 and before, we get all sorts of sec issues.  At minimum we should consider the assertion for a ride-along for 63.0.x and land in 60ESR.

Comment 3

[Andrew Overholt [:overholt]]

In the interest of investigating quickly, I'll needinfo a few people who may know.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

(In reply to Randell Jesup [:jesup] from comment #2)
> Many crashes (in 60.*/esr60) with UAF/wildptr/EXEC/priv-instruction
> failures).  In 64 we get an assertion or maybe null-deref:
> MOZ_CRASH(Looks like bug 1488480/1405521, with aCreator failing to create
> Document.prototype)
CCing bz, since he added the assertion in bug 1499150

Comment 5

[Boris Zbarsky [:bzbarsky]]

If you're seeing that assertion, that's bug 1488480 (and bug 1405521), like it says.  Its signature has been shifting as I've been adding diagnostic code on nightly to try to pin it down.  That's not related to the crash this was originally filed on, as far as I can tell.

Comment 6

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

So you believe the sec crashes (which appear to have stopped since you added the assertion) are unrelated to the assertion?  It's possible something else landed the made the sec crash go away... but my suspicion (based on no real data!) is that your assertion may be (also) catching these sec bugs.  In any case, uplifting it to ESR and 63 (even if it's just a safety crash) may be worthwhile

Comment 7

[Boris Zbarsky [:bzbarsky]]

Well, the crash from comment 0 was under MouseEvent_Binding::Wrap.  My assertions are only in code that can be reached while wrapping HTMLDocument instances, so the crash from comment 0 would be unrelated to those assertions, yes.

> In any case, uplifting it to ESR and 63

Just to be clear, these assertions are diagnostic code.  They are not meant to ship.  I have an open bug tracking backing them out from 64 so we don't ship them by accident.  They can in theory happen in various cases when we would not otherwise crash.

Comment 8

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

See https://crash-stats.mozilla.com/report/index/2daa719b-cd58-43f5-9bb8-c57330181010, or https://crash-stats.mozilla.com/report/index/358953f6-8f6c-4a2b-afbf-91ee90181019 (etc - exclude 64*)

looks like a number of different stacks; I haven't seen one of those with MouseEvent yet (didn't look at that many) -- only 17 of 517 in the last few months had MouseEvent on the stack

Comment 9

[Boris Zbarsky [:bzbarsky]]

> See https://crash-stats.mozilla.com/report/index/2daa719b-cd58-43f5-9bb8-c57330181010, or https://crash-stats.mozilla.com/report/index/358953f6-8f6c-4a2b-afbf-91ee90181019 

Right, those would not hit my MOZ_CRASH, because they're not for a document.

Comment 10

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

Well, that may be good then, since the sec crashes seem to be gone in 64.  

The next question would be: what made them go away?  517 in 3 months may be way too low to pinpoint a landing date, especially if it's in nightly and not an uplift.

Whatever made them go away, we want that as a possible point release ride-along, and definitely for ESR60

Comment 11

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Hmm, I have no idea (canceling ni?).

Comment 12

[Edgar Chen [:edgar]]

The crash from comment 0 was EXCEPTION_ACCESS_VIOLATION_READ and if we query with it the result is 71 in the last 6 months [2].
There are number of different stacks, I only see two crash with MouseEvent on the stack.

And the last similar crash was https://crash-stats.mozilla.com/report/index/e0c57718-7db4-4dfa-8de6-d7d510181119 whose build id is 20181115150739, but it is hard to tell if something else landed fixes it or just because the reproduce rate becomes pretty low.

[1] https://hg.mozilla.org/mozilla-central/annotate/a9616aaeff87448588d57c295e16eb4caec420fb/dom/bindings/BindingUtils.cpp#l4198
[2] https://crash-stats.mozilla.com/signature/?product=Firefox&reason=~EXCEPTION_ACCESS_VIOLATION_READ&release_channel=beta&release_channel=nightly&signature=mozilla%3A%3Adom%3A%3AGetPerInterfaceObjectHandle&date=%3E%3D2018-05-28T13%3A02%3A09.000Z&date=%3C2018-11-28T02%3A02%3A09.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_sort=-build_id&page=1#reports

Comment 13

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Edgar Chen [:edgar] from comment #12)
> The crash from comment 0 was EXCEPTION_ACCESS_VIOLATION_READ and if we query
> with it the result is 71 in the last 6 months [2].
> There are number of different stacks, I only see two crash with MouseEvent
> on the stack.

One was on 62, one as comment 0 showed on 64.
Assuming that this bug focuses on this scope EXCEPTION_ACCESS_VIOLATION_READ + MouseEvent, in this case, it's not clear for me this should remain P1. 

> 
> And the last similar crash was
> https://crash-stats.mozilla.com/report/index/e0c57718-7db4-4dfa-8de6-
> d7d510181119 whose build id is 20181115150739, but it is hard to tell if
> something else landed fixes it or just because the reproduce rate becomes
> pretty low.

EXCEPTION_ACCESS_VIOLATION_READ crashes seem disappear in 64 and considering the low rate, I'm thinking of marking "stalled" for now. That said, I think it's worth tracking different stacks in different bugs.

I am also modifying the status for firefox65 that it doesn't look like 65 is affected. 

> [1]
> https://hg.mozilla.org/mozilla-central/annotate/
> a9616aaeff87448588d57c295e16eb4caec420fb/dom/bindings/BindingUtils.cpp#l4198
> [2]
> https://crash-stats.mozilla.com/signature/
> ?product=Firefox&reason=~EXCEPTION_ACCESS_VIOLATION_READ&release_channel=beta
> &release_channel=nightly&signature=mozilla%3A%3Adom%3A%3AGetPerInterfaceObjec
> tHandle&date=%3E%3D2018-05-28T13%3A02%3A09.000Z&date=%3C2018-11-
> 28T02%3A02%3A09.
> 000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_colum
> ns=platform&_columns=reason&_columns=address&_columns=install_time&_sort=-
> build_id&page=1#reports

Comment 14

[David Lawrence [:dkl]]

Removing employee no longer with company from CC list of private bugs.

Comment 15

[Andrew McCreight [:mccr8]]

Crashes with this signature still exist, but the volume is low and I don't see much that is unusually alarming from a security perspective in the crashes, so let's just close this.

Comment 16

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

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