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

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Bob Clary [:bc] (inactive)]

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
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/09/2012-09-11-mozilla-central-debug/firefox-18.0a1.en-US.debug-win32.installer.exe
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/09/2012-09-12-mozilla-central-debug/firefox-18.0a1.en-US.debug-win32.installer.exe


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

Crash reason:  EXCEPTION_ACCESS_VIOLATION_EXEC
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

Comment 1

[Boris Zbarsky [:bzbarsky]]

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
1557    
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

Comment 2

[Boris Zbarsky [:bzbarsky]]

We need valgrind here.  Something is just corrupting memory all over.

Comment 3

[Bob Clary [:bc] (inactive)]

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.

Comment 4

[Paul Adenot (:padenot)]

Attachment: 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 5

[Paul Adenot (:padenot)]

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).

Comment 6

[Paul Adenot (:padenot)]

Attachment: 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.

Comment 7

[Boris Zbarsky [:bzbarsky]]

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.

Comment 8

[Paul Adenot (:padenot)]

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.

Comment 9

[David Anderson [:dvander] - inactive, e-mail if emergency]

Attachment: fix

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.

Comment 10

[David Anderson [:dvander] - inactive, e-mail if emergency]

https://hg.mozilla.org/integration/mozilla-inbound/rev/fe5b75aa2b16

Comment 12

[Andrew McCreight [:mccr8]]

I'm going to assume this is sec-crit giving the high volume of weird crash stacks.

Comment 13

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/fe5b75aa2b16

Comment 15

[Robert Kaiser]

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

Comment 16

[Robert Kaiser]

Oh, I see this was landed when trunk was still 18 (9/25, not 10/25), so everything is fine. :)

Comment 17

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Yes, it's on aurora:

https://hg.mozilla.org/releases/mozilla-aurora/rev/fe5b75aa2b16

Comment 18

[Ioana (away)]

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:
https://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=contains&query=nsCSSFrameConstructor%3A%3AProcessChildren%28nsFrameConstructorState%26amp%3B%2C%20nsIContent%2A%2C%20nsStyleContext%2A%2C%20nsIFrame%2A%2C%20bool%2C%20nsFrameItems%26amp%3B%2C%20bool%2C%20PendingBinding%2A%2C%20nsIFrame%2A%29&reason_type=contains&date=11%2F28%2F2012%2014%3A55%3A44&range_value=4&range_unit=weeks&hang_type=any&process_type=any&do_query=1&signature=nsCSSFrameConstructor%3A%3AProcessChildren%28nsFrameConstructorState%26%2C%20nsIContent%2A%2C%20nsStyleContext%2A%2C%20nsIFrame%2A%2C%20bool%2C%20nsFrameItems%26%2C%20bool%2C%20PendingBinding%2A%2C%20nsIFrame%2A%29


If either of you guys working on this bug think the new crash has to do with this bug, please let me know:
https://crash-stats.mozilla.com/report/index/69da5e78-b05f-4f89-ae3b-500872121125

Comment 19

[Ioana (away)]

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:
https://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=contains&query=nsCSSFrameConstructor%3A%3AProcessChildren%28nsFrameConstructorState%26amp%3B%2C%20nsIContent%2A%2C%20nsStyleContext%2A%2C%20nsIFrame%2A%2C%20bool%2C%20nsFrameItems%26amp%3B%2C%20bool%2C%20PendingBinding%2A%2C%20nsIFrame%2A%29&reason_type=contains&date=11%2F28%2F2012%2014%3A55%3A44&range_value=4&range_unit=weeks&hang_type=any&process_type=any&do_query=1&signature=nsCSSFrameConstructor%3A%3AProcessChildren%28nsFrameConstructorState%26%2C%20nsIContent%2A%2C%20nsStyleContext%2A%2C%20nsIFrame%2A%2C%20bool%2C%20nsFrameItems%26%2C%20bool%2C%20PendingBinding%2A%2C%20nsIFrame%2A%29

Comment 20

[Tracy Walker [:tracy]]

mass remove verifyme requests greater than 4 months old