Closed Bug 617048 Opened 14 years ago Closed 14 years ago

Firefox 4.0b8pre crash in [@ nsXBLService::GetBinding(nsIContent*, nsIURI*, int, nsIPrincipal*, int*, nsXBLBinding**, nsTArray<nsIURI*, nsTArrayDefaultAllocator>&) ] [@ nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0xbf3fb3 ]

Categories

(Core :: XBL, defect)

Product:
Core
Component:
XBL
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla2.0b8
Tracking Flags:
Tracking Status
blocking2.0 --- beta8+

People

(Reporter: marcia, Assigned: jst)

References

Details

(Keywords: crash, Whiteboard: [looks to be resolved])

Crash Data

Seen while reviewing crash stats. Crashes started showing up using the 2010120400 build. http://tinyurl.com/3abk98e to the crashes so far which are all Windows.

Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	nsXBLService::GetBinding 	content/xbl/src/nsXBLService.cpp:917
1 	xul.dll 	nsXBLService::GetBinding 	content/xbl/src/nsXBLService.cpp:917
2 	xul.dll 	nsXBLService::GetBinding 	content/xbl/src/nsXBLService.cpp:917
3 	xul.dll 	nsXBLService::GetBinding 	content/xbl/src/nsXBLService.cpp:917
4 	xul.dll 	nsXBLService::LoadBindings 	content/xbl/src/nsXBLService.cpp:589
5 	xul.dll 	nsCSSFrameConstructor::AddFrameConstructionItemsInternal 	layout/base/nsCSSFrameConstructor.cpp:5134
6 	xul.dll 	nsCSSFrameConstructor::ProcessChildren 	layout/base/nsCSSFrameConstructor.cpp:9644
7 	xul.dll 	nsCSSFrameConstructor::ConstructFrameFromItemInternal 	layout/base/nsCSSFrameConstructor.cpp:3822
8 	xul.dll 	nsCSSFrameConstructor::ConstructFramesFromItem 	layout/base/nsCSSFrameConstructor.cpp:5515
9 	xul.dll 	nsCSSFrameConstructor::ConstructFramesFromItemList 	layout/base/nsCSSFrameConstructor.cpp:9543
10 	xul.dll 	nsCSSFrameConstructor::ProcessChildren 	layout/base/nsCSSFrameConstructor.cpp:9659
11 	xul.dll 	nsCSSFrameConstructor::ConstructFrameFromItemInternal 	layout/base/nsCSSFrameConstructor.cpp:3822
12 	xul.dll 	nsCSSFrameConstructor::ConstructFramesFromItem 	layout/base/nsCSSFrameConstructor.cpp:5515
13 	xul.dll 	nsCSSFrameConstructor::ConstructFramesFromItemList 	layout/base/nsCSSFrameConstructor.cpp:9543
14 	xul.dll 	nsCSSFrameConstructor::ProcessChildren 	layout/base/nsCSSFrameConstructor.cpp:9659
15 	xul.dll 	nsCSSFrameConstructor::ConstructFrameFromItemInternal 	layout/base/nsCSSFrameConstructor.cpp:3822
16 	xul.dll 	nsCSSFrameConstructor::ConstructFramesFromItem 	layout/base/nsCSSFrameConstructor.cpp:5515
17 	xul.dll 	nsCSSFrameConstructor::ConstructFramesFromItemList 	layout/base/nsCSSFrameConstructor.cpp:9543
18 	xul.dll 	nsCSSFrameConstructor::ContentRangeInserted 	layout/base/nsCSSFrameConstructor.cpp:7215
19 	xul.dll 	nsCSSFrameConstructor::ContentInserted 	layout/base/nsCSSFrameConstructor.cpp:6832
20 	xul.dll 	nsCSSFrameConstructor::IssueSingleInsertNofications 	layout/base/nsCSSFrameConstructor.cpp:6415
21 	xul.dll 	nsCSSFrameConstructor::GetRangeInsertionPoint 	layout/base/nsCSSFrameConstructor.cpp:6473
22 	xul.dll 	nsCSSFrameConstructor::ContentAppended 	layout/base/nsCSSFrameConstructor.cpp:6562
23 	xul.dll 	PresShell::ContentAppended 	layout/base/nsPresShell.cpp:5065
24 	xul.dll 	nsNodeUtils::ContentAppended 	content/base/src/nsNodeUtils.cpp:148
25 	xul.dll 	nsINode::doInsertChildAt 	content/base/src/nsGenericElement.cpp:3608
26 	xul.dll 	nsGenericElement::InsertChildAt 	content/base/src/nsGenericElement.cpp:3536
27 	xul.dll 	nsINode::ReplaceOrInsertBefore 	content/base/src/nsGenericElement.cpp:4278
28 	xul.dll 	nsIDOMNode_AppendChild 	obj-firefox/js/src/xpconnect/src/dom_quickstubs.cpp:5307
29 	xul.dll 	nsIDOMNode_AppendChild 	obj-firefox/js/src/xpconnect/src/dom_quickstubs.cpp:5302
30 	mozjs.dll 	JS_DHashTableRawRemove 	js/src/jsdhash.cpp:712
31 	mozjs.dll 	js::PropertyCache::fill 	js/src/jspropertycache.cpp:139
32 	mozjs.dll 	GetAtomFromBytecode 	js/src/jspropertycache.cpp:316
33 	mozjs.dll 	js::Interpret 	js/src/jsinterp.cpp:4748
34 	mozjs.dll 	js::RunScript 	js/src/jsinterp.cpp:657
35 	mozjs.dll 	js::Invoke 	js/src/jsinterp.cpp:737
36 	mozjs.dll 	js_fun_apply 	js/src/jsfun.cpp:2296
37 	mozjs.dll 	js::Interpret 	js/src/jsinterp.cpp:4748
38 	mozjs.dll 	js::RunScript 	js/src/jsinterp.cpp:657
39 	mozjs.dll 	js::Invoke 	js/src/jsinterp.cpp:737
40 	mozjs.dll 	js::ExternalInvoke 	js/src/jsinterp.cpp:858
41 	mozjs.dll 	JS_CallFunctionValue 	js/src/jsapi.cpp:4971
42 	xul.dll 	nsXPCWrappedJSClass::CallMethod 	js/src/xpconnect/src/xpcwrappedjsclass.cpp:1694
43 	xul.dll 	nsXPCWrappedJS::CallMethod 	js/src/xpconnect/src/xpcwrappedjs.cpp:588
44 	xul.dll 	PrepareAndDispatch 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:114
45 	xul.dll 	SharedStub 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:141
46 	xul.dll 	NS_InvokeByIndex_P 	xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:102
One comment mentioned they clicked on the Tools Menu.
Hmm.  Any idea what the pushlog regression range is here?
looks similar to Bug 616723 which started happening around dec 4.
         nsXBLService::GetBinding.nsIContent.,.nsIURI.,.int,.nsIPrincipal.,.int.,.nsXBLBinding..,.nsTArray.nsIURI.,.nsTArrayDefaultAllocator...
date     total    breakdown by build
         crashes  count build, count build, ...

20101201   
20101202   
20101203   
20101204 14 4.0b8pre2010120403 
20101205 46  	 27 4.0b8pre2010120503, 
        	 19 4.0b8pre2010120403,
this should probably block beta8 until we understand it better.
status2.0: --- → ?
I'd still really appreciate an answer to comment 2 if someone knows it.  The date-to-buildid mapping is not exactly straightforward.  :(
on 2010/12/04 we started seeing crashes in 4.0b8pre builds from 2010/12/04 03a
http://tinyurl.com/2aslcgz shows a possible range since the crashes started showing up in the 20101204 build.
I'm not 100% positive, but I am fairly certain the build from the 3rd was based on:

    http://hg.mozilla.org/mozilla-central/rev/0ff6d5984287

and I think the build from the 4th was:

    http://hg.mozilla.org/mozilla-central/rev/cd392793b0c0

I think that would be the range.
So: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0ff6d5984287&tochange=cd392793b0c0

Nothing in there touched XBL, though there were the <select> changes to frame construction...  but I don't see how those would cause problems in GetBinding.
Like I said, my methodology could be wrong. I believe there can be multiple builds throughout the day for nightlies (?) and I possibly picked a later one.
As stated in bug 616723 comment 1, with the combined related signatures it is #1 top crasher.
> Like I said, my methodology could be wrong. I believe there can be multiple
> builds throughout the day for nightlies (?) and I possibly picked a later one.
It is possible to have several nightlies but in this case there is only one on 12/03 and 12/04 (check for on: ftp://ftp.mozilla.org/pub/firefox/nightly/2010-12-03-*-mozilla-central/ and ftp://ftp.mozilla.org/pub/firefox/nightly/2010-12-04-*-mozilla-central/).
The regression range in comment 10 is right.
This should be blocking 2.0.
blocking2.0: --- → ?
OK.  We're hitting this via the classinfo codepath too, btw, reducing the likelihood that the frame constructor changes are the problem.

Bug 605672 did change clone/adopt stuff, which might affect XBL.  Peter, is it possible that we're now JS-wrapping XBL anonymous content "too early" or something?
pread pretty evenly across windows versions, and not much interesting in the
urls.   also doesn't seem to be many repeatable crashes or crashes near start
up.

checking ---
nsXBLService::GetBinding.nsIContent.,.nsIURI.,.int,.nsIPrincipal.,.int.,.nsXBLBinding..,.nsTArray.nsIURI.,.nsTArrayDefaultAllocator...
20101206-crashdata.csv
found in: 4.0b8pre
release total-crashes
             
nsXBLService::GetBinding.nsIContent.,.nsIURI.,.int,.nsIPrincipal.,.int.,.nsXBLBinding..,.nsTArray.nsIURI.,.nsTArrayDefaultAllocator...
crashes
                         pct.
all     344897  177     0.000513197
4.0b8pre        4788    177     0.0369674

os breakdown
nsXBLService::GetBinding.nsIContent.,.nsIURI.,.int,.nsIPrincipal.,.int.,.nsXBLBinding..,.nsTArray.nsIURI.,.nsTArrayDefaultAllocator...Total
32
Win5.1  0.47
Win6.0  0.12
Win6.1  0.38

domains of sites
  16 \N//
  15 http://www.orkut.com.br
   9 jar:file://
   4 http://www.youtube.com
   4 http://www.google.com.br
   4 http://www.baixaki.com.br
   4 http://fpdownload.adobe.com
   3 about:blank//
   2 https://addons.mozilla.org

 urls for testing
  16 \N
   4
http://fpdownload.adobe.com/get/flashplayer/current/install_flash_player.exe
   3 about:blank
   2
jar:file:///C:/Program%20Files/Minefield/omni.jar!/chrome/toolkit/content/mozapps/extensions/extensions.xul
   2
http://www.orkut.com.br/ads/gen/afci005.html#google_ad_width=300&google_ad_height=250&google_image_size=300x250&google_ad_format=300x250_as_new&google_color_border=ffffff&google_color_bg
=ffffff&google_color_text=000000&google_color_link=3767be&google_ad_c
   2 http://www.orkut.com.br/Home

   1 http://www.youtube.com/watch?v=vLP863_epAI
   1 http://www.youtube.com/watch?v=9gurvNONtY8
   1 http://www.youtube.com/watch?v=8wxOVn99FTE&NR=1
   1 http://www.youtube.com/results?search_query=fr&aq=f

Correlation to startup or time of session
177 total crashes for
nsXBLService::GetBinding.nsIContent.,.nsIURI.,.int,.nsIPrincipal.,.int.,.nsXBLBinding..,.nsTArray.nsIURI.,.nsTArrayDefaultAllocator...
on 20101206-crashdata.csv
 startup crashes inside 30 sec.
16 startup crashes inside 3 min.
3 repeated crashes inside 3 min. of last crash
Summary: Firefox 4.0b8pre crash in [@ nsXBLService::GetBinding(nsIContent*, nsIURI*, int, nsIPrincipal*, int*, nsXBLBinding**, nsTArray<nsIURI*, nsTArrayDefaultAllocator>&) ] → Firefox 4.0b8pre crash in [@ nsXBLService::GetBinding(nsIContent*, nsIURI*, int, nsIPrincipal*, int*, nsXBLBinding**, nsTArray<nsIURI*, nsTArrayDefaultAllocator>&) ] [@ nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0xbf3fb3 ]
blocking2.0: ? → beta8+
status2.0: ? → ---
this appears to also go by the following signatures

>nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0xbf3643
>nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0xbf3fb3
>nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0xb18ae3
>nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0xb17ae3
>nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0xb9e76f
>nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0xb9f71f
>nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0xb9d827
>nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0xbcc16f
>nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0xbf234b
_purecall | nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | nsContentUtils::CanCallerAccess(nsPIDOMWindow*)
>nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0xc39f07
>nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0xb16adb
>nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0xbcb1cf
>nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0xb9d717
>nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0xc38baf
>nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0xb81f17
>nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0xb80f37
>nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0xc36b9f
>nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0xb9c877
>nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0xb87f47
>@0x0 | nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | nsXBLService::GetBinding(nsIContent*, nsIURI*, int, nsIPrincipal*, int*, nsXBLBinding**, nsTArray<nsIURI*, nsTArrayDefaultAllocator>&)
>nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0xc37ef7
>nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0xbf78f3
>nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0xbca16f
>nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0xb9fb87
>nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0xb9ebd7
(In reply to comment #16)
> Bug 605672 did change clone/adopt stuff, which might affect XBL.  Peter, is it
> possible that we're now JS-wrapping XBL anonymous content "too early" or
> something?

I don't see how. The only possible behaviour change that I find is that we now always use the ownerDocument as the parent in adoptNode, we used to use the window. The other changes should just make us crash less, but if they don't fix a crash they don't change behaviour.
Nothing else in the range really jumps out at me.  We should probably try backing things out one at a time and see what happens or something.  :(
(In reply to comment #9)
> I'm not 100% positive, but I am fairly certain the build from the 3rd was based
> on:
> 
>     http://hg.mozilla.org/mozilla-central/rev/0ff6d5984287
> 
> and I think the build from the 4th was:
> 
>     http://hg.mozilla.org/mozilla-central/rev/cd392793b0c0
> 
> I think that would be the range.

This looks correct based on:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/12/2010-12-03-03-mozilla-central/firefox-4.0b8pre.en-US.win32.txt
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/12/2010-12-04-03-mozilla-central/firefox-4.0b8pre.en-US.win32.txt

There don't appear to be any mozilla-central win32/x86 builds between them, and since the crashes started coming in at 6:39am on the 4th, it's unlikely to be a later one.
not many comments to go on, but a few users are talking about UI manipulation or attempting to open a new tab kinds of actions when crashing.

http://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=exact&query=&range_value=4&range_unit=weeks&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=nsCOMPtr_base%3A%3Aassign_from_qi%28nsQueryInterface%2C%20nsID%20const%26%29%20|%20nsXBLService%3A%3AGetBinding%28nsIContent*%2C%20nsIURI*%2C%20int%2C%20nsIPrincipal*%2C%20int*%2C%20nsXBLBinding**%2C%20nsTArray%3CnsIURI*%2C%20nsTArrayDefaultAllocator%3E%26%29

nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0xb81f17 Tried to open new tab via CTRL+Thttp://www.novinky.cz/

nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0x97da23 DAS IST nicht mehr normal dieser seiß firefox stürzst die ganze zeit ab bitte behebt das sonst werde ich zu einer bombe \N

nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0xb18fe3 "I CTRL-clicked on a link to ""Your Account"" on Amazon.com, and the browser crashed." http://www.irs.gov/newsroom/article/0,,id=232017,00.html

nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0xb18fe3 i clicked on a link to open in a new tab (on a site that needs authentication)http://fbc.fanball.com/resources/rts_rightrail_ad.html

nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0xbf3643 Gmail, bugzilla open.https://bugzilla.mozilla.org/show_bug.cgi?id=567973

nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0xba861f Open a new tabhttp://www.facebook.com/pagelet/....

nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0xb18fe3 I was closing firefox, crashed without reason.\N

nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0xa397c7 диотыhttp://pass.yandex.ru/login?retpath=...

nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0x972f6f facebook

nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0x972f6f facebook

nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0x972f6f email

nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0xb18fe3 crash always in win7 64  http://www.facebook.com/ajax/home/...
One commonality in some of the reports is that they have tons of extensions installed.

I haven't been able to reproduce with any of the URLs that Chris provides.

And it seems that some of the reporters mentioned that everything becomes corrupted.
http://crash-stats.mozilla.com/report/index/0c41b051-a6ca-4854-9b6d-6b60b2101207 is one example of some of the extensions I have seen in the reports, and I have seen reports that have even more extensions than that. And he gives a pretty good description of the corruption he is seeing related to the DM, Toolbar, etc.
The crashes I looked at linked from comment 0 mostly seemed to have no extensions, though.  :(
What's the right next step on this. Per Boris' comment 20, is our only option at this point to back things out to see if this disappears? If so who would do that?
As discussed after today's product meeting:

What we have here is strong evidence that these crashes started on December 4th, and a heavy implication that something in the range from comment 10 is at the root of this.

I suggest that we back out as much of that range as possible and respin nightlies to see if it does, indeed, eliminate this crash in nightly users. If it does, we can ship beta 8, then slowly re-add the fixes and figure out the cause.

There will be some things we'll need to keep. I suggest:

 - things which don't touch XBL at all
 - things which are b8 blockers
 - NPOTB changes
Whiteboard: [need to back out changeset in comment 10]
> - things which don't touch XBL at all

That's really everything in the range; that's the problem.
I'm a little suspicious of:
http://hg.mozilla.org/mozilla-central/rev/9ddbf8ab23a5
(which could cause Windows-only problems).
just an update on the volume for this

The [@ nsXBLService::GetBinding(nsIContent*, nsIURI*, int, nsIPrincipal*, int*,
nsXBLBinding**, nsTArray<nsIURI*, nsTArrayDefaultAllocator>&) ] signature has
gone from zero to 222 crashes on dec. 7.

The long tail of signatures like:

  nsCOMPtr_base::assign_from_qi.nsQueryInterface,.nsID.const.....xul.dll@ ****

and noted in comment 18 have continued to expand and have gone from 20-40
crashes per day before dec 4. steadly climbing to 417 crashes per day on dec.
7.

so total number of crashes is now hitting around 620 per day.

That would put it in the ballpark of a high volume regression like we saw with
beta5 that caused the beta6 respin in Bug 589296.  if we decide to go out with
beta 8 with this problem, we should at least have the problem diagnosed and a
fix ready to respin with in case it blows up as we add a million beta testers.
I've looked at two minidumps, one for the assign_with_qi | GetBinding signature and one for the GetBinding signature.

I think the immediate cause of the crash is that we're doing this:
915     rv = GetBinding(aBoundElement, baseProto->BindingURI(), aPeekOnly,
916                     child->NodePrincipal(), aIsReady,
917                     getter_AddRefs(baseBinding), aDontExtendURIs);
with baseProto being a dangling pointer, most likely one that was previously a good pointer but has been freed.  In the GetBinding signature, we get an access violation because the page is no longer mapped; in the assign_with_qi | GetBinding signature we succeed in reading the free memory, but get a bad value out of it when we try to QI the pointer inside the inner GetBinding call.
After looking at the XBL code a bit, I could imagine getting into the situation of having a bad pointer if we somehow load the same binding document twice, causing us to through away the first occurrence of the XBLDocumentInfo for it (and thus all the prototype bindings).
I think this could in fact happen.  Say binding A in XBL document xbldocA inherits from binding B in XBL document xbldocB.  Say further that we have two documents that both have elements using binding A.

First we instantiate binding A for an element in doc1.  We get an xbldocumentinfo for xbldocA, then get the xbldocumentinfo for xbldocB, then return the whole thing.  Now doc1 has strong pointers to both xbldocumentinfos in its binding manager.  We wait for doc1 to go away.

Now we instantiate binding A for an elements in doc2.  When we get the xbldocumentinfo for xbldocA we get a cache hit in the XUL prototype cache for the xbldocumentinfo.  But for some reason xbldocB is NOT in the xul proto cache, so we have a dangling reference to its prototype bindings in the data we got back for xbldocA.

So for this to happen, a chrome binding needs to inherit from a non-chrome binding.  Or the xul proto cache needs to be confused... 

Note that just disabling the xul proto cache won't cause this problem, since the key is that binding A is being used in two different documents and they share a pointer to xbldocA; the only way to do that is for xbldocA to live in the proto cache.
I backed out the two changes that were believed to be suspicious:
http://hg.mozilla.org/mozilla-central/pushloghtml?changeset=c7b784648b02

If that changeset is green, I'll ask for a new Windows nightly.
Assignee: nobody → jst
it took about 6 hours before the first regression crashes showed up on build 20101204030328 so we might have some good data by tomorrow morning.
Good news! 9 hours after its release, I don't see this crash signature or any other related crash signatures on build 20101208161455.
Yup, still nothing AFAICT. I'll keep this bug open a bit longer and I'll keep watching for crashes, but so far so good!
Whiteboard: [need to back out changeset in comment 10] → [looks to be resolved]
You guys rock! I don't see any signatures yet today. I suppose we don't know if it was caused by one of those checkins or some combination of the two?
I'm comfortable marking this fixed at this point.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b8
(In reply to comment #41)
> You guys rock! I don't see any signatures yet today. I suppose we don't know if
> it was caused by one of those checkins or some combination of the two?

Correct, we'll need to re-land those changes (after beta8) spaced apart enough to tell which change caused this, and then take it from there.
Crash Signature: [@ nsXBLService::GetBinding(nsIContent*, nsIURI*, int, nsIPrincipal*, int*, nsXBLBinding**, nsTArray<nsIURI*, nsTArrayDefaultAllocator>&) ] [@ nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | xul.dll@0xbf3fb3 ]
Blocks: 1092381
No longer blocks: 1092381
You need to log in before you can comment on or make changes to this bug.