1197321 - crash in nsXBLService::GetBinding(nsIContent*, nsIURI*, bool, nsIPrincipal*, bool*, nsXBLBinding**, nsTArray<T>&)

Status: RESOLVED FIXED

(Core :: XBL, defect)

Description

[(Away)]

This bug was filed from the Socorro interface and is 
report bp-34325fa8-1371-47be-a01b-eef832150818.
=============================================================

This signature dramatically rose in volume on v40 on 8/20 (explosiveness score 44.9). I suspect addons or binaries may be involved; I'm waiting for correlation files to be backfilled after the recent glitch.

Frame 	Module 	Signature 	Source
0 	xul.dll 	nsXBLService::GetBinding(nsIContent*, nsIURI*, bool, nsIPrincipal*, bool*, nsXBLBinding**, nsTArray<nsIURI*>&) 	dom/xbl/nsXBLService.cpp
1 	xul.dll 	nsXBLService::GetBinding(nsIContent*, nsIURI*, bool, nsIPrincipal*, bool*, nsXBLBinding**, nsTArray<nsIURI*>&) 	dom/xbl/nsXBLService.cpp
2 	xul.dll 	nsXBLService::GetBinding(nsIContent*, nsIURI*, bool, nsIPrincipal*, bool*, nsXBLBinding**) 	dom/xbl/nsXBLService.cpp
3 	xul.dll 	nsXBLService::LoadBindings(nsIContent*, nsIURI*, nsIPrincipal*, nsXBLBinding**, bool*) 	dom/xbl/nsXBLService.cpp
4 	xul.dll 	mozilla::dom::Element::WrapObject(JSContext*, JS::Handle<JSObject*>) 	dom/base/Element.cpp
5 	xul.dll 	mozilla::dom::DocumentBinding::getAnonymousElementByAttribute 	obj-firefox/dom/bindings/DocumentBinding.cpp
6 	xul.dll 	js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) 	js/src/vm/Interpreter.cpp

Comment 1

[[:philipp]]

numerous reports have no extensions present and a small portion of the crashes seem to come from os x as well, so it may not necessarily be caused by external factors of that sort...

Comment 2

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

Would be nice to have link to some search result of these crashes, not only one report.
(crash-stats is so difficult to use these days that figuring out how to get the right search results
takes always some time)

Comment 3

[Robert Kaiser]

(In reply to Olli Pettay [:smaug] (high review load) from comment #2)
> Would be nice to have link to some search result of these crashes, not only
> one report.

Clicking on the link in the Crash Signature field of this bug directly gets you to a page that has some summary stats of this signature and a "Reports" tab that lists more crashes with this signature.

Comment 4

[:Harald Kirschner :digitarald]

Maybe it helps: I just had this crash when developing on an addon. I was using a fresh profile with only https://addons.mozilla.org/en-US/firefox/addon/autoinstaller/ and my addon. jpm watchpost sideloaded the addon on changes for continues development. The browser crashed randomly during the session once.

Comment 5

[mkdante381]

https://crash-stats.mozilla.com/report/index/6497c79a-8b25-4b61-8731-586b52150827

Comment 6

[Robert Kaiser]

This seems to be on the rise in Firefox 40 release over the last weekend and is 2.3% of all 40.0.03 crashes over the last 3 days.

Comment 7

[(Away)]

The most common crash address is 0x5a5a5a5a.

This is seen on all desktop platforms, and the URLs and comments are all over the map. Perhaps the sudden rise in volume was triggered through an ad network?

Comment 8

[(Away)]

|aURI| is the poison in the top frame nsXBLService::GetBinding, which means |baseBindingURL| is poison in the parent frame (also nsXBLService::GetBinding).

Which means that either |baseProto| or |protoBinding| is dead, but I can't tell which:

  nsXBLPrototypeBinding* baseProto = protoBinding->GetBasePrototype();
  if (baseProto) {
    baseBindingURI = baseProto->BindingURI();
  }
  else {
    baseBindingURI = protoBinding->GetBaseBindingURI();

bz can you help?

Comment 9

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

I filed Bug 1202844 yesterday to deal with this.
https://bugzilla.mozilla.org/show_bug.cgi?id=1202844#c0 was my guess

Comment 10

[Boris Zbarsky [:bzbarsky]]

Yeah, that's my best guess too.

Which of baseProto and protoBinding is dead, I don't know.  It depends on the exact structure of the XBL in question...

Comment 11

[Andrew McCreight (out of office until 8/21) [:mccr8]]

This is really just the same thing as bug 1202844, but I'll rate it separately for now.

Comment 12

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Given that bug 1202844 is fixed, is this fixed too now?

Comment 13

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

Unfortunately no. See https://bugzilla.mozilla.org/show_bug.cgi?id=1204669

Comment 14

[Andrew McCreight (out of office until 8/21) [:mccr8]]

I'll assign this to smaug as he's been looking at it. Adjust as desired.

Comment 15

[Liz Henry (:lizzard) (relman/hg->git project)]

Tracking since this is sec-critical.

Comment 16

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

bug 1204669 may have fixed this. Need to look at crash-stat within a week or so.

Comment 17

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

[FIXED]...hopefully. I'll look at the crash-stat some more, and file yet another bug if I see related issues.

Comment 18

[Andrew McCreight (out of office until 8/21) [:mccr8]]

I didn't see any recent crashes with this on any branch, though I'm not sure if that has made it out to a beta or not.

Comment 19

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Based on comment 17, I do not feel the need to track this for 41, updating 41-status to wontfix to be complete.

Comment 20

[Sylvestre Ledru [:Sylvestre]]

Unfortunately, this is still happening (we have crash reports from the latest 42 beta). It is topcrash #38.

Comment 21

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

Would be helpful to have a link to the crashes.
(c-s.m.c has so bizarre UI that I tend to find different things on different days)

I don't see XBL anywhere in https://crash-stats.mozilla.com/topcrasher/products/Firefox/versions/42.0b?days=7
which is what the crash-stat UI tells should be the topcrashers for 42 beta.

Comment 22

[Sylvestre Ledru [:Sylvestre]]

Olly, on this url: https://crash-stats.mozilla.com/report/list?signature=nsXBLService%3A%3AGetBinding%28nsIContent*%2C%20nsIURI*%2C%20bool%2C%20nsIPrincipal*%2C%20bool*%2C%20nsXBLBinding**%2C%20nsTArray%3CT%3E%26%29
in the product section, I can find 42.0b4 for example.

Comment 23

[[:philipp]]

these are the two reports from 42.0b4:
https://crash-stats.mozilla.com/search/?product=Firefox&signature=%3DnsXBLService%3A%3AGetBinding%28nsIContent*%2C+nsIURI*%2C+bool%2C+nsIPrincipal*%2C+bool*%2C+nsXBLBinding**%2C+nsTArray%3CT%3E%26%29&version=42.0b4&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#crash-reports

Comment 24

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

Unfortunately stack traces in those reports don't really make sense.

Comment 25

[Sylvestre Ledru [:Sylvestre]]

We only have a few crashes in 42 beta (5). 
Leaving the value "affected", I will have a look once we release 42 to see if it spikes or not.

Comment 26

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

Still haven't see any new crash reports where stack would be sane.
The old stack traces were different, so I claim that at least an issue in the relevant code was fixed.

Sylvestre, do you see any normal looking stack traces in crash-stat?

Comment 27

[Sylvestre Ledru [:Sylvestre]]

I haven't seen any new stack at all in 43, 44 & 45.
42 RC had 2 crashes, 42 had 1 crash. Let's close it. Sorry for the noise at the end of this process.

Comment 28

[Daniel Veditz [:dveditz]]

There's no patch here, but the two "depends on" bugs were fixed on ESR 38