If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

RESOLVED FIXED in Firefox 18



JavaScript Engine
5 years ago
4 years ago


(Reporter: bc, Assigned: dvander)


(Blocks: 2 bugs, {crash, regression, sec-critical})

crash, regression, sec-critical
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(firefox17 unaffected, firefox18+ verified, firefox19+ verified, firefox-esr10 unaffected)


(Whiteboard: [ion:p1:fx18], URL)


(2 attachments, 1 obsolete attachment)



5 years ago
1. http://jsbin.com/iscroll-floating-headers/14/edit

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
Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=96287ad60bef&tochange=6e78c3efd115

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 http://sisyphus.bughunter.ateam.phx1.mozilla.com/bughunter/media/minidumps/2012-09-20-21/4c798652-87e8-4603-b981-679f7d2e1c04.txt
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.

Comment 3

5 years ago
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.
Created attachment 663584 [details] [diff] [review]
Valgrind log using linux64 and valgrind compiled from svn

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
Created attachment 663597 [details]
same setup, with --smc-check=all-non-file

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
tracking-firefox18: --- → ?
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.


5 years ago
Assignee: general → dvander

Comment 9

5 years ago
Created attachment 664187 [details] [diff] [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+

Comment 10

5 years ago


5 years ago
Whiteboard: [ion:p1:fx18]


5 years ago
Duplicate of this bug: 792226
I'm going to assume this is sec-crit giving the high volume of weird crash stacks.
status-firefox-esr10: --- → unaffected
status-firefox17: --- → unaffected
status-firefox18: --- → affected
Keywords: sec-critical
Blocks: 719114
Last Resolved: 5 years ago
status-firefox18: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla18


5 years ago
tracking-firefox18: ? → +
Duplicate of this bug: 793271

Comment 15

5 years ago
So I guess that should be uplifted to Aurora 18? Bug 792698 says the fix worked.

Comment 16

5 years ago
Oh, I see this was landed when trunk was still 18 (9/25, not 10/25), so everything is fine. :)
Yes, it's on aurora:

status-firefox19: --- → fixed
tracking-firefox19: --- → +
Flags: in-testsuite?
Group: core-security

Comment 18

5 years ago
Verified as fixed with the steps in comment 0 on Firefox 18 beta 1 - 20121121075611 (Mac OS X 10.7.5, Windows 7, Ubuntu 12.04).

There is one post-fix crash in Socorro though:

If either of you guys working on this bug think the new crash has to do with this bug, please let me know:
status-firefox18: fixed → verified
Keywords: verifyme
QA Contact: ioana.budnar

Comment 19

5 years ago
Verified as fixed with the steps in comment 0 on:
Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20100101 Firefox/19.0
Mozilla/5.0 (X11; Linux i686; rv:19.0) Gecko/20100101 Firefox/19.0
BuildID: 20130109111322

There are no crashes newer than 11/21/2012 in Socorro either:
status-firefox19: fixed → verified
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.