Open Bug 860333 Opened 9 years ago Updated 5 years ago
Shutdown crash in DR
_State::~DR _State when running debug build with GECKO _DISPLAY _REFLOW _RULES _FILE
STR: 1. As described at https://mxr.mozilla.org/mozilla-central/source/layout/doc/frame_reflow_debug.html , create a text file containing just this text on the first line: "* 1" (no quotes) Name it e.g. /tmp/rules.txt 2. Start a debug build, as follows: GECKO_DISPLAY_REFLOW_RULES_FILE=/tmp/rules.txt ./dist/bin/firefox -profile deleteme -no-remote about:blank 3. Exit. ACTUAL RESULTS: Shutdown crash (technically an assert in jemalloc.c), during a 'delete' invocation in ~DR_State, from this line in jemalloc.c: > RELEASE_ASSERT((run->regs_mask[elm] & (1U << bit)) == 0);
Summary: Crash in DR_State::~DR_State when running debug build with GECKO_DISPLAY_REFLOW_RULES_FILE → Shutdown crash in DR_State::~DR_State when running debug build with GECKO_DISPLAY_REFLOW_RULES_FILE
Reporting with an unpatched debug mozilla-central build, up-to-date as of last night (at cset 9db46ddfb517).
In an old-ish debug build (from 2012-05-01), the STR trigger: *** glibc detected *** ./firefox: corrupted double-linked list: 0x0000000002620640 *** Needless to say, this would be a security issue if it weren't for the fact that it requires a non-standard build (a debug build) and runtime config (special env variable and text file).
I can reproduce this in debug nightlies from 2011, as well: https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2011/06/2011-06-01-03-mozilla-central-debug/ So this isn't something that regressed recently. Note: In old nightlies, the bug is a bit sporadic. I just performed the STR 3 times with the 2011-06-01 debug nightly, and I got no symptoms the first time, a crash reporter dialog the second time, and a "*** glibc detected *** ./firefox-bin: corrupted double-linked list: 0x00000000028d09d0 ***" the third time. CC'ing zwol since I think he worked on this stuff at one point.
I don't *remember* working on this ... [checks hg blame] ... oh, right, bug 562093. The diff in there doesn't look like it should have introduced or removed any crashes.
Here's a minimal testcase that currently triggers this patch's NS_ERROR.
Comment on attachment 754227 [details] [diff] [review] breaktest 1 Sorry, disregard comment 5 -- posted on wrong bug.
Attachment #754227 - Attachment is obsolete: true
So I just debugged this a bit; I think it's related to ending up with duplicate nodes in DR_state.mFrameTreeLeaves as a result of the AppendElement call in DR_State::DeleteTreeNode(): https://searchfox.org/mozilla-central/rev/78ac0ceba97bd2deed847a8d0ae86ccf7a8887bf/layout/generic/nsFrame.cpp#11180 and then only deleting one of the duplicate nodes while running, and leaving the other for shutdown, when the memory has been freed.
... which might be related to the frame being a block on which we call XULLayout, and that XULLayout calls Reflow, so we should conceptually have a single frame with two nested cookies. Or something like that; I probably need to debug again to be sure.
(I don't understand why DR_State::CreateTreeNode is so complicated. Why isn't this just a stack, where the parent node is always the last node in mFrameTreeLeaves?)
You need to log in before you can comment on or make changes to this bug.