Closed
Bug 784365
Opened 12 years ago
Closed 12 years ago
runtime abort in nsIFrame::BuildDisplayListForChild
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 781279
People
(Reporter: kairo, Unassigned)
Details
(Keywords: assertion, crash, regression)
Crash Data
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•12 years ago
|
||
(In reply to Robert Kaiser (:kairo@mozilla.com) 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.
Keywords: assertion
Summary: crash in nsIFrame::BuildDisplayListForChild → abort in nsIFrame::BuildDisplayListForChild
Updated•12 years ago
|
Summary: abort in nsIFrame::BuildDisplayListForChild → runtime abort in nsIFrame::BuildDisplayListForChild
Reporter | ||
Comment 2•12 years ago
|
||
GetOffsetToCrossDoc?
Hrm, this means that this is another case of the re-regression of bug 781265, then, I guess. :(
Comment 3•12 years ago
|
||
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?)
Reporter | ||
Comment 4•12 years ago
|
||
I asked about this there, thanks. I still wonder why this signature only appeared a day later than the re-regression apparently happened, though.
Reporter | ||
Comment 5•12 years ago
|
||
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).
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•