Closed Bug 793257 Opened 7 years ago Closed 7 years ago

Crash [@ nsCSSFrameConstructor::ProcessChildren(nsFrameConstructorState&, nsIContent*, nsStyleContext*, nsIFrame*, bool, nsFrameItems&, bool, PendingBinding*, nsIFrame*) ]


(Core :: JavaScript Engine, defect, critical)

Not set



Tracking Status
firefox17 --- unaffected
firefox18 + verified
firefox19 + verified
firefox-esr10 --- unaffected


(Reporter: bc, Assigned: dvander)


(Blocks 2 open bugs, )


(Keywords: crash, regression, sec-critical, Whiteboard: [ion:p1:fx18])


(2 files, 1 obsolete file)


2. Crash nsCSSFrameConstructor::ProcessChildren(nsFrameConstructorState&, nsIContent*, nsStyleContext*, nsIFrame*, bool, nsFrameItems&, bool, PendingBinding*, nsIFrame*) 

Windows XP/7 Nightly are the most reliable. I did see one crash on this url with this signature on Linux 32bit and other signatures on Linux and OSX.

Locally on OSX 10.7 I got a null deref in nsINodeInfo:GetDocument -> nsINode::OwnerDoc -> nsCSSFrameConstructor::ResolveStyleContext.

Breakpad's exploitable rates this as highly exploitable on Windows.

Found regression between 20120910183953-20120911183952

Operating system: Windows NT
                  6.1.7601 Service Pack 1
CPU: x86
     GenuineIntel family 6 model 37 stepping 1
     1 CPU

Crash address: 0x40000000

Thread 0 (crashed)
 0  0x40000000
    eip = 0x40000000   esp = 0x00257ad4   ebp = 0x00257ae8   ebx = 0x00000001
    esi = 0x00000000   edi = 0xffffff81   eax = 0x40000000   ecx = 0x0a122d30
    edx = 0x08a77980   efl = 0x00210202
    Found by: given as instruction pointer in context
 1  xul.dll!nsCSSFrameConstructor::ProcessChildren(nsFrameConstructorState &,nsIContent *,nsStyleContext *,nsIFrame *,bool,nsFrameItems &,bool,PendingBinding *,nsIFrame *) [nsCSSFrameConstructor.cpp : 9960 + 0x2c]
    eip = 0x666a076b   esp = 0x00257af0   ebp = 0x00257c30
    Found by: previous frame's frame pointer
 2  xul.dll!nsCSSFrameConstructor::ConstructBlock(nsFrameConstructorState &,nsStyleDisplay const *,nsIContent *,nsIFrame *,nsIFrame *,nsStyleContext *,nsIFrame * *,nsFrameItems &,bool,PendingBinding *) [nsCSSFrameConstructor.cpp : 11022 + 0x25]
    eip = 0x666a2467   esp = 0x00257c38   ebp = 0x00257cb4
    Found by: call frame info
 3  xul.dll!nsCSSFrameConstructor::ConstructNonScrollableBlock(nsFrameConstructorState &,nsCSSFrameConstructor::FrameConstructionItem &,nsIFrame *,nsStyleDisplay const *,nsFrameItems &,nsIFrame * *) [nsCSSFrameConstructor.cpp : 4526 + 0x50]
    eip = 0x66693beb   esp = 0x00257cbc   ebp = 0x00257cf0
    Found by: call frame info
 4  xul.dll!nsCSSFrameConstructor::ConstructFrameFromItemInternal(nsCSSFrameConstructor::FrameConstructionItem &,nsFrameConstructorState &,nsIFrame *,nsFrameItems &) [nsCSSFrameConstructor.cpp : 3615 + 0x25]
    eip = 0x666914bc   esp = 0x00257cf8   ebp = 0x00257e08
    Found by: call frame info

full report (requires mpt access) at
When I run this locally, I get a crash with this stack:

#0  moz_abort () at extraMallocFuncs.c:116
#1  0x0000000100031550 in arena_run_reg_alloc (run=0x12ae77000, bin=0x1004002f0) at jemalloc.c:3166
#2  0x000000010003103b in arena_bin_malloc_easy (arena=0x100400040, bin=0x1004002f0, run=0x12ae77000) at jemalloc.c:3922
#3  0x000000010002fd55 in arena_malloc_small (arena=0x100400040, size=64, zero=false) at jemalloc.c:4123
#4  0x000000010002fa7e in arena_malloc (arena=0x100400040, size=64, zero=false) at jemalloc.c:4205
#5  0x000000010001aa4b in imalloc (size=64) at jemalloc.c:4217
#6  0x000000010001a8b7 in je_malloc (size=64) at jemalloc.c:6301
#7  0x000000010001f459 in zone_malloc (zone=0x10005d000, size=64) at jemalloc.c:6919
#8  0x00007fff8dfd8183 in malloc_zone_malloc ()
#9  0x00007fff8dfd8c91 in realloc ()
#10 0x0000000100613e78 in PR_Realloc (ptr=0x0, size=64) at prmem.c:450

which is ... troubling.

Then I ran again, and this time got a crash on this code:

(gdb) frame
#0  0x0000000102e83e0b in nsGenericElement::UnbindFromTree (this=0x149581800, aDeep=true, aNullParent=true) at nsGenericElement.cpp:1562
1562          mAttrsAndChildren.ChildAt(i)->UnbindFromTree(true, false);
(gdb) list
1558        for (i = 0; i < n; ++i) {
1559          // Note that we pass false for aNullParent here, since we don't want
1560          // the kids to forget us.  We _do_ want them to forget their binding
1561          // parent, though, since this only walks non-anonymous kids.
1562          mAttrsAndChildren.ChildAt(i)->UnbindFromTree(true, false);
1563        }
(gdb) p n
$1 = 4
(gdb) p i
$2 = 0
(gdb) p mAttrsAndChildren.ChildAt(0)
$4 = (Cannot access memory at address 0xfffb800146a1a700
(gdb) p mAttrsAndChildren.ChildAt(1)
$5 = (Cannot access memory at address 0xfff9000000000000
(gdb) p mAttrsAndChildren.ChildAt(2)
$6 = (Cannot access memory at address 0xfff9000000000000
(gdb) p mAttrsAndChildren.ChildAt(3)
$7 = (nsTextNode *) 0x1495f2c00
We need valgrind here.  Something is just corrupting memory all over.
Not sure if this is helpful but on OSX 10.7 with a fresh svn valgrind build I got

==29704== Thread 1:
==29704== Invalid read of size 8
==29704==    at 0x8C7B6EC: nsGenericElement::UnbindFromTree(bool, bool) (nsGenericElement.cpp:1562)
==29704==    by 0x8EC941C: nsGenericHTMLElement::UnbindFromTree(bool, bool) (nsGenericHTMLElement.cpp:1770)
==29704==    by 0x8C7B705: nsGenericElement::UnbindFromTree(bool, bool) (nsGenericElement.cpp:1562)
==29704==    by 0x8EC941C: nsGenericHTMLElement::UnbindFromTree(bool, bool) (nsGenericHTMLElement.cpp:1770)
==29704==    by 0x8C8EB76: nsINode::doRemoveChildAt(unsigned int, bool, nsIContent*, nsAttrAndChildArray&) (nsINode.cpp:1367)
==29704==    by 0x8D1EF55: mozilla::dom::FragmentOrElement::RemoveChildAt(unsigned int, bool) (FragmentOrElement.cpp:1020)
==29704==    by 0x8EC76BF: nsGenericHTMLElement::SetInnerHTML(nsAString_internal const&) (nsGenericHTMLElement.cpp:1341)
==29704==    by 0x8F1FAA7: nsHTMLDivElement::SetInnerHTML(nsAString_internal const&) (nsHTMLDivElement.cpp:34)
==29704==    by 0x9AD5DA9: nsIDOMHTMLElement_SetInnerHTML(JSContext*, JS::Handle<JSObject*>, JS::Handle<jsid>, int, JS::MutableHandle<JS::Value>) (dom_quickstubs.cpp:14537)
==29704==    by 0xB439658: js::CallJSPropertyOpSetter(JSContext*, int (*)(JSContext*, JS::Handle<JSObject*>, JS::Handle<jsid>, int, JS::MutableHandle<JS::Value>), JS::Handle<JSObject*>, JS::Handle<jsid>, int, JS::MutableHandle<JS::Value>) (jscntxtinlines.h:456)
==29704==    by 0xB435D2E: js::Shape::set(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSObject*>, bool, JS::MutableHandle<JS::Value>) (jsscopeinlines.h:334)
==29704==    by 0xB429911: js_NativeSet(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSObject*>, js::Shape*, bool, bool, JS::Value*) (jsobj.cpp:4256)
==29704==  Address 0xfff9000000000000 is not stack'd, malloc'd or (recently) free'd

just before valgrind started crapping out with lots of ==29704== Signal 11 being dropped from thread 0's queue messages. If you need it let me know and I'll try Linux later when I get a chance.
dbaron asked if I could valgrind this, since I had a Linux with a valgrind from svn handy. Attached is the log from the moment I press enter to load the page to the segfault.
Comment on attachment 663584 [details] [diff] [review]
Valgrind log using linux64 and valgrind compiled from svn

(forgot --smc-check=all-non-file, rerunning with that flag now).
Attachment #663584 - Attachment is obsolete: true
Attachment #663584 - Attachment is patch: true
Here is the relevant part of the log, ran with --smc-check=all-non-file. It took a dozen run to reproduce.
Hrm.  But no indication of any invalid writes?  :(  How is that memory getting bogus, then?

Though I guess the regression range from comment 0 tells us how: IonMonkey.
Assignee: nobody → general
Component: Layout → JavaScript Engine
There is certainly much more output since IonMonkey landed than when I ran Firefox under Valgrind before, since it used to be more or less valgrind-clean before.

However, I don't see invalid writes, only "Conditional jump or move depends on uninitialised value(s)". I have logs if needed.
Assignee: general → dvander
Attached patch fixSplinter Review
We narrowed this down to call object logic in Ion and Luke found the actual bug (and desk r+'d the patch) by auditing it. We're writing before the beginning of slots vectors.
Attachment #664187 - Flags: review+
Whiteboard: [ion:p1:fx18]
Duplicate of this bug: 792226
I'm going to assume this is sec-crit giving the high volume of weird crash stacks.
Blocks: 719114
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla18
Duplicate of this bug: 793271
So I guess that should be uplifted to Aurora 18? Bug 792698 says the fix worked.
Oh, I see this was landed when trunk was still 18 (9/25, not 10/25), so everything is fine. :)
Flags: in-testsuite?
Group: core-security
mass remove verifyme requests greater than 4 months old
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.