Created attachment 607258 [details] sample crash report 1. http://members.home.nl/bdr/files/fusker.html?http://members.home.nl/bdr/files/fusker.html%3Fhttp://i.crackedcdn.com/phpimages/photoshop/%5B1-9%5D/%5B1-9%5D/%5B1-9%5D/%5B1-9%5D%5B00-99%5D_slide.jpg 2. Consume CPU and RAM until you crash ###!!! ASSERTION: Inserting node that already has parent: '!aKid->GetNodeParent()', file c:/work/mozilla/builds/nightly/mozilla/cont ent/base/src/nsGenericElement.cpp, line 3757 Crashes Nightly/14, Aurora/13, Beta/12, Firefox/11 on Windows XP and Windows 7. Firefox/11 bp-9c5f6e84-81d0-49ff-83f4-385fd2120319 [@ EMPTY: no crashing thread identified; corrupt dump ] Nightly/14 bp-6d234ff4-7365-4282-8f8b-db3ca2120319 [@ EMPTY: no crashing thread identified; corrupt dump ] Operating system: Windows NT 6.1.7601 Service Pack 1 CPU: x86 GenuineIntel family 6 model 37 stepping 1 2 CPUs Crash reason: EXCEPTION_ACCESS_VIOLATION_EXEC Crash address: 0xffffffffb0fdfdfd Thread 0 (crashed) 0 0xb0fdfdfd eip = 0xb0fdfdfd esp = 0x0052aba8 ebp = 0x0052abc4 ebx = 0x1f4bb790 esi = 0x063479b0 edi = 0x04e605c0 eax = 0xff00a5f0 ecx = 0xdddddddd edx = 0xb0fdfdfd efl = 0x00010286 Found by: given as instruction pointer in context Note the heap fenceposts 0xfd and the deleted memory. Other reports show 0xfeeefeee which is freed Heap memory from HeapFree. Common pattern in all reports so far is ecx = 0xdddddddd Running under windbg I crash at [@ nsiNodeInfo::NodeInfoManager ] More reports are available in Bughunter.
Christian, can you run your OOM tool with this page and see if making certain allocations fail leads to badness?
I'm testing this right now but it'll take a while until I can post possible results :)
Kyle: are you volunteering to take this bug? :-)
Andrew says he can look into this. Tracking for 12 onwards, but whether we can fix this for 12 etc depends on what the fix ends up looking like...
It is possible that this is fixed by bug 737875. The assertion here and the crash there both have "aKid" and I derived that crash from the testcase here using OOM testing. Since khuey has a fix for that bug, maybe bc can retest this once that fix landed.
The page is a script that creates a page with a bunch of inline images (656100 to be precise). Running it on a bogus URL (so that it wasn't loading images at the same time) caused a lot of these: WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file /Users/amccreight/mz/cent3/content/base/src/nsGenericElement.cpp, line 3780
I'll wait to see if the other bug fixed this before investigating further.
I retested Beta/12, Aurora/13 and Nightly/14 in automation and only crashed in Windows 7 32 bit Beta/12, Aurora/13 and Nightly/14 without getting a crash dump. The last time Beta or Aurora showed an exploitable crash was 3/20 on Windows 7 64bit with 32bit builds. Testing locally I only have seen oom aborts Windows XP 32bit and Windows 7 32bit Nightly/14. On Window 7 64bit (32bit builds) it just cranks along without crashing. Testing locally with Aurora/Beta on Windows XP, I've seen the exploitable crashes with eax and ecx = 0xfeeefeee. Aurora/Beta on Windows 7 32bit only showed oom. Not sure why automation didn't show the exploitable crashes on xp. Based on local testing I would say this is fixed on Nightly though. I haven't checked if the particular patch is responsible though.
Should we close/dupe this bug?
lets call it fixed by bug 737875
bug 737875 has now been checked in to beta/aurora/esr10
As given by the testcase-wanted keyword, is there a testcase QA can use to verify this fix? Comment 0 perhaps?
The testcase-wanted was to ask someone to develop a reduced test case but I don't know if it is possible to get a reproducible one given the nature of these low/oom bugs.
(In reply to Bob Clary [:bc:] from comment #14) > The testcase-wanted was to ask someone to develop a reduced test case but I > don't know if it is possible to get a reproducible one given the nature of > these low/oom bugs. Given that we'll qa- this bug and put faith in crashstats data.
Can this be verified through verification of bug 737875?
(In reply to Al Billings [:abillings] from comment #16) > Can this be verified through verification of bug 737875? I assert that to be the case, yes.