1. http://www.superconsole.it/ 2. assert http://www.superconsole.it/ Windows XP/Windows 7 so far. I have a local test case that asserts after reloads and am reducing now, but it is taking a while. Operating system: Windows NT 6.1.7600 CPU: x86 GenuineIntel family 6 model 44 stepping 2 1 CPU Crash reason: EXCEPTION_ACCESS_VIOLATION_WRITE Crash address: 0x0 Thread 0 (crashed) 0 mozjs.dll!JS_Assert [jsutil.cpp : 73 + 0x0] eip = 0x6959811a esp = 0x001cc238 ebp = 0x001cc238 ebx = 0x03540030 esi = 0x00007018 edi = 0x0786c760 eax = 0x00000000 ecx = 0xae4858c4 edx = 0x6f161d48 efl = 0x00010202 Found by: given as instruction pointer in context 1 mozjs.dll!js::PCVal::toShape() [jspropertycache.h : 112 + 0x21] eip = 0x694cce59 esp = 0x001cc240 ebp = 0x001cc250 Found by: call frame info 2 mozjs.dll!js::mjit::stubs::SetName<0>(js::VMFrame &,JSAtom *) [StubCalls.cpp : 165 + 0xa] eip = 0x6964de1a esp = 0x001cc258 ebp = 0x001cc2a0 Found by: call frame info 3 mozjs.dll!js::mjit::stubs::SetGlobalName<0>(js::VMFrame &,JSAtom *) [StubCalls.cpp : 316 + 0xa] eip = 0x6964e827 esp = 0x001cc2a8 ebp = 0x001cc2b0 Found by: call frame info 4 mozjs.dll!js::mjit::ic::SetGlobalName(js::VMFrame &,js::mjit::ic::SetGlobalNameIC *) [MonoIC.cpp : 330 + 0x26] eip = 0x6969d564 esp = 0x001cc2b8 ebp = 0x001cc2d8 Found by: call frame info 5 mozjs.dll!js::mjit::EnterMethodJIT(JSContext *,JSStackFrame *,void *,js::Value *) [MethodJIT.cpp : 748 + 0x14] eip = 0x6964428a esp = 0x001cc320 ebp = 0x001cc318 Found by: call frame info with scanning see also Bug 627486 and ss because it is and shapes are involved.
Can we get a reduced testcase, or at least capture the website in case it goes away?
Assignee: general → jorendorff
Blocking final+, but if this isn't sg:critical, we can unblock.
blocking2.0: --- → final+
Whiteboard: [sg:critical?] → [sg:critical?][hardblocker]
Its a NULL crash. Why do we think it is sg:crit?
(In reply to comment #3) > Its a NULL crash. Why do we think it is sg:crit? It's a NULL crash because it's an assert. It is "sg:critical?" presumably because it's a type safety violation, where something that is not a Shape* is cast to that type. To really know if it's exploitable, we'd have to reproduce the assert and do a detailed analysis, but at first glance it doesn't look too serious. The shape itself is not written, but it does control some writes, e.g., a slot write. I can't repro this. I loaded the URL in a debug build, and nothing special happens. So it might just be a WFM.
I tried the url and the local version I had saved and could not reproduce with a recent build. I'll try again tomorrow.
not blocking final on anything that isn't easily reproducible. moving to .x for now.
blocking2.0: final+ → .x+
Created attachment 515560 [details] test.zip If my bisecting is to be believed, this was fixed by: user: Bill McCloskey <email@example.com> date: Wed Feb 23 10:23:59 2011 -0800 summary: Bug 606960 - Purge property cache even for eval scripts (r=brendan,a=beltzner) which landed on tm 2/23 and merged into mc 2/25. To run the test, unzip and load tests/www.superconsole.it/index.html it may take several minutes to assert.
Bill, does comment 7 sound reasonable?
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
That makes total sense -- awesome find by Bill, that was a bad bug. /be
Yeah, based on the stack, this looks like precisely the sort of thing that should have been fixed in bug 606960.
You need to log in before you can comment on or make changes to this bug.