784365 - runtime abort in nsIFrame::BuildDisplayListForChild

Status: RESOLVED DUPLICATE of bug 781279

(Core :: Layout, defect)

Description

[Robert Kaiser]

This bug was filed from the Socorro interface and is 
report bp-da7a444f-8da0-4b91-84f7-b3c8c2120821 .
============================================================= 

More crashes at https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort%28char%20const*%20const%29%20|%20NS_DebugBreak_P%20|%20nsIFrame%3A%3ABuildDisplayListForChild%28nsDisplayListBuilder*%2C%20nsIFrame*%2C%20nsRect%20const%26%2C%20nsDisplayListSet%20const%26%2C%20unsigned%20int%29

Frames:
0 	mozalloc.dll 	mozalloc_abort 	memory/mozalloc/mozalloc_abort.cpp:23
1 	xul.dll 	NS_DebugBreak_P 	xpcom/base/nsDebugImpl.cpp:410
2 	xul.dll 	nsIFrame::BuildDisplayListForChild 	layout/generic/nsFrame.cpp:2295

Below this, the stacks differ, some ending there interestingly (like the one at the top of this comment), some like bp-7cc29865-5bb2-4180-b140-13d552120821 coming from nsGlobalWindow::GetMozInnerScreenX, some like bp-a54ee276-1fb2-4178-8db6-51e192120821 from nsDisplayList::HitTest (but 
GetMozInnerScreenX even shows up there), some from entirely different places.

This started happening in Nightly 17.0a1 in the build of 2012-08-19, so the regression window is the day before this build started, roughly this one: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2012-08-18+00%3A00%3A00&enddate=2012-08-19+03%3A00%3A00

I'm not good at finding what is suspect, but searching for "displaylist" in that range only points to bug 783700. dholbert, dbaron, could this be connected?

Comment 1

[Daniel Holbert [:dholbert]]

(In reply to Robert Kaiser (:[e-mail]) from comment #0)
> I'm not good at finding what is suspect, but searching for "displaylist" in
> that range only points to bug 783700. dholbert, dbaron, could this be
> connected?

Unlikely, I think.

That _only_ touched nsColumnSetFrame::BuildDisplayList() -- but from skimming a few of the crash reports, it looks like they're all in nsBoxFrame::BuildDisplayList, and nsColumnSetFrame never shows up anywhere in the stack.

e.g.: in all of these ones I inspected.
 bp-799e6729-46d2-4bae-93d8-fe1b02120821
 bp-5cf7c490-0074-48fe-b931-274242120821
 bp-90df2972-a4bf-4d6e-abf8-1635c2120821
 bp-cfaff103-9559-4c93-a2bc-918af2120821
 bp-a2b595f2-9319-4527-97d2-8d8572120819

Also, more interestingly -- these crash reports all have this under "App Notes":
xpcom_runtime_abort(###!!! ABORT: trying to get the offset between frames in different document hierarchies?: file e:/builds/moz2_slave/m-cen-w32-ntly/build/layout/generic/nsFrame.cpp, line 4347)

and they "crash" via a call to NS_DebugBreak_P.  So I believe these are aborts, rather than crashes.

So, that means these shouldn't be exploitable, as long as we're hitting the abort, which is some consolation.

That abort is here:
> 4340     NS_RUNTIMEABORT("trying to get the offset between frames in different "
> 4341                     "document hierarchies?");
http://hg.mozilla.org/mozilla-central/annotate/f9a8fdb08193/layout/generic/nsFrame.cpp#l4340

Its method (GetOffsetToCrossDoc) doesn't show up in the crash report backtraces, strangely -- maybe because it's inlined -- but I'm not sure who's calling it.

Comment 2

[Robert Kaiser]

GetOffsetToCrossDoc?
Hrm, this means that this is another case of the re-regression of bug 781265, then, I guess. :(

Comment 3

[Daniel Holbert [:dholbert]]

Yup, that's the abort these crash stacks are hitting.  It looks like scoobidiver already brought this up there, in bug 781265 comment 14. (though mats ended up suggested filing a new bug, so maybe this could be that bug?)

Comment 4

[Robert Kaiser]

I asked about this there, thanks. I still wonder why this signature only appeared a day later than the re-regression apparently happened, though.

Comment 5

[Robert Kaiser]

OK, for now, I'll dupe this against bug 781279, let's see if that really fixes this one as well (when a fix is found).