Closed
Bug 522817
Opened 15 years ago
Closed 15 years ago
"Assertion failure: sprop->slot < OBJ_SCOPE(object)->freeslot"
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: jruderman, Assigned: dmandelin)
References
()
Details
(Keywords: assertion, testcase)
Attachments
(2 files, 5 obsolete files)
Loading http://www.ceibal.edu.uy/ triggeres Assertion failure: sprop->slot < OBJ_SCOPE(object)->freeslot, at /Users/jruderman/central/js/src/jsscope.h:705 (Testing on mozilla-central)
![]() |
||
Comment 1•15 years ago
|
||
I got a ~4,000 line testcase coming up soon, still reducing...
Keywords: testcase
Comment 2•15 years ago
|
||
Dave, I think this is the top-crasher you were hunting and trying to reproduce.
![]() |
||
Comment 3•15 years ago
|
||
Now ~3,500 lines. I'm still reducing it but I'd thought to post it here for devs to look at it first. Backtrace: Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000002, 0x0000000000000000 Crashed Thread: 0 Thread 0 Crashed: 0 libmozjs.dylib 0x003a55ff JS_Assert + 63 (jsutil.cpp:69) 1 libmozjs.dylib 0x003fb3c4 JSScope::methodWriteBarrier(JSContext*, JSScopeProperty*, long) + 180 (jsscope.h:705) 2 libmozjs.dylib 0x003c7b91 __ZL18MethodWriteBarrierP9JSContextP8JSObjectP15JSScopePropertyS2_ + 119 3 ??? 0x16076d8d 0 + 369585549 4 libmozjs.dylib 0x003e74ac __ZL11ExecuteTreeP9JSContextPN7nanojit8FragmentERjPP10VMSideExit + 1564 5 libmozjs.dylib 0x003f2d29 js_MonitorLoopEdge(JSContext*, unsigned int&, MonitorReason) + 1035 6 libmozjs.dylib 0x003063ef js_Interpret + 43073 (jsops.cpp:923) 7 libmozjs.dylib 0x003262ea js_Execute + 1124 (jsinterp.cpp:1600) 8 libmozjs.dylib 0x00342873 __ZL8obj_evalP9JSContextP8JSObjectjPlS3_ + 2165 9 libmozjs.dylib 0x00327009 js_Invoke + 2399 (jsinterp.cpp:1365) 10 libmozjs.dylib 0x00313406 js_Interpret + 96344 (jsops.cpp:2291) 11 libmozjs.dylib 0x003262ea js_Execute + 1124 (jsinterp.cpp:1600) 12 libmozjs.dylib 0x00296ee1 JS_EvaluateUCScriptForPrincipals + 331 (jsapi.cpp:5054) 13 libgklayout.dylib 0x1161e71e nsJSContext::EvaluateString(nsAString_internal const&, void*, nsIPrincipal*, char const*, unsigned int, unsigned int, nsAString_internal*, int*) + 1002 (nsJSEnvironment.cpp:1682) 14 libgklayout.dylib 0x113d310a nsScriptLoader::EvaluateScript(nsScriptLoadRequest*, nsString const&) + 954 (nsScriptLoader.cpp:686) 15 libgklayout.dylib 0x113d33b0 nsScriptLoader::ProcessRequest(nsScriptLoadRequest*) + 328 (nsScriptLoader.cpp:600) 16 libgklayout.dylib 0x113d5219 nsScriptLoader::ProcessScriptElement(nsIScriptElement*) + 3775 (nsScriptLoader.cpp:554) 17 libgklayout.dylib 0x113d0e45 nsScriptElement::MaybeProcessScript() + 387 (nsScriptElement.cpp:193) 18 libgklayout.dylib 0x114bf627 nsHTMLScriptElement::MaybeProcessScript() + 31 (nsHTMLScriptElement.cpp:539) 19 libgklayout.dylib 0x114bdb89 nsHTMLScriptElement::DoneAddingChildren(int) + 33 (nsHTMLScriptElement.cpp:476) 20 libgklayout.dylib 0x114f220b HTMLContentSink::ProcessSCRIPTEndTag(nsGenericHTMLElement*, int) + 287 (nsHTMLContentSink.cpp:2955) 21 libgklayout.dylib 0x114f3396 SinkContext::CloseContainer(nsHTMLTag, int) + 1388 (nsHTMLContentSink.cpp:1013) 22 libgklayout.dylib 0x114f3a95 HTMLContentSink::CloseContainer(nsHTMLTag) + 301 (nsHTMLContentSink.cpp:2267) 23 libhtmlpars.dylib 0x147142c1 CNavDTD::CloseContainer(nsHTMLTag, int) + 625 (CNavDTD.cpp:2704) 24 libhtmlpars.dylib 0x147198b7 CNavDTD::HandleEndToken(CToken*) + 965 (CNavDTD.cpp:1627) 25 libhtmlpars.dylib 0x14718074 CNavDTD::HandleToken(CToken*) + 1724 (CNavDTD.cpp:718) 26 libhtmlpars.dylib 0x14719fdb CNavDTD::BuildModel(nsITokenizer*, int, int, nsCString const*) + 911 (CNavDTD.cpp:301) 27 libhtmlpars.dylib 0x147248e3 nsParser::BuildModel() + 289 (nsParser.cpp:2422) 28 libhtmlpars.dylib 0x1472a5bc nsParser::ResumeParse(int, int, int) + 546 (nsParser.cpp:2320) 29 libhtmlpars.dylib 0x1472ba9b nsParser::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned int, unsigned int) + 771 (nsParser.cpp:2950) 30 libdocshell.dylib 0x10e13201 nsDocumentOpenInfo::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned int, unsigned int) + 99 (nsURILoader.cpp:306) 31 libnecko.dylib 0x00cce40e nsBaseChannel::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned int, unsigned int) + 116 (nsBaseChannel.cpp:708) 32 libnecko.dylib 0x00ce1da9 nsInputStreamPump::OnStateTransfer() + 777 (nsInputStreamPump.cpp:508) 33 libnecko.dylib 0x00ce2304 nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) + 138 (nsInputStreamPump.cpp:398) 34 libxpcom_core.dylib 0x00578956 nsInputStreamReadyEvent::Run() + 100 (nsStreamUtils.cpp:113) 35 libxpcom_core.dylib 0x005ac16e nsThread::ProcessNextEvent(int, int*) + 676 (nsThread.cpp:527) 36 libxpcom_core.dylib 0x00531a62 NS_ProcessPendingEvents_P(nsIThread*, unsigned int) + 146 37 libwidget_mac.dylib 0x09969e01 nsBaseAppShell::NativeEventCallback() + 181 (nsBaseAppShell.cpp:122) 38 libwidget_mac.dylib 0x0991b1cf nsAppShell::ProcessGeckoEvents(void*) + 521 (nsAppShell.mm:418) 39 com.apple.CoreFoundation 0x923503c5 CFRunLoopRunSpecific + 3141 40 com.apple.CoreFoundation 0x92350aa8 CFRunLoopRunInMode + 88 41 com.apple.HIToolbox 0x9051a2ac RunCurrentEventLoopInMode + 283 42 com.apple.HIToolbox 0x90519ffe ReceiveNextEventCommon + 175 43 com.apple.HIToolbox 0x90519f39 BlockUntilNextEventMatchingListInMode + 106 44 com.apple.AppKit 0x96bfe6d5 _DPSNextEvent + 657 45 com.apple.AppKit 0x96bfdf88 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128 46 com.apple.AppKit 0x96bf6f9f -[NSApplication run] + 795 47 libwidget_mac.dylib 0x099199b7 nsAppShell::Run() + 291 (nsAppShell.mm:770) 48 libtoolkitcomps.dylib 0x0a5f515e nsAppStartup::Run() + 148 (nsAppStartup.cpp:182) 49 XUL 0x000aabc2 XRE_main + 14048 (nsAppRunner.cpp:3420) 50 org.mozilla.firefox 0x00002862 main + 714 (nsBrowserApp.cpp:156) 51 org.mozilla.firefox 0x000024e2 start + 54
Reporter | ||
Comment 6•15 years ago
|
||
Also happens at http://mj12net.org/index.php/system-administrator-interview-cheat-sheet.html
![]() |
||
Comment 7•15 years ago
|
||
That's about all I can manage for today. Jesse, would you like to further reduce this? ;-)
Attachment #407042 -
Attachment is obsolete: true
![]() |
||
Updated•15 years ago
|
Attachment #407157 -
Attachment description: 100-line testcase → ~100-line testcase
Assignee | ||
Comment 8•15 years ago
|
||
If it's getting hard to reduce, don't sweat it further for now. I can probably debug the cases you have so far. But one thing I'm curious about is exactly how you repro this yourself. I tried the 115-line test case earlier today and it did not crash right away, but it did crash after I clicked Refresh about 30 times. Is it the same for you or can you get it to crash with no or fewer reloads?
Assignee: general → dmandelin
Reporter | ||
Comment 9•15 years ago
|
||
(Replaced eval with dump, then pasted into jsbeautifier.)
Attachment #407157 -
Attachment is obsolete: true
Reporter | ||
Comment 10•15 years ago
|
||
Attachment #407182 -
Attachment is obsolete: true
Assignee | ||
Comment 11•15 years ago
|
||
This crash appears to be caused by a problem in TraceRecorder::setProp, right about here: /* * Setting a function-valued property might need to rebrand the object, so * we emit a call to the method write barrier. There's no need to guard on * this, because functions have distinct trace-type from other values and * branded-ness is implied by the shape, which we've already guarded on. */ if (scope->branded() && VALUE_IS_FUNCTION(cx, v) && entry->directHit()) { ...call MethodWriteBarrier Note that the comment says we've already guarded on the shape. But in fact, (1) the shape guard is generated further down in this function, and (2) the shape seen at the point of the crash is not equal to the shape at recording time (so we must not have yet executed a guard on this shape). This should be easy to fix by reordering the code.
Comment 12•15 years ago
|
||
The method write barrier came in the patch for bug 471214, so not in 1.9.1 (or yet in 1.9.2 thanks to sayrer watching blocking regression bugs). So this is not "the" bug, but it's a good catch -- thanks to all for finding it. Reordering should fix as dmandelin notes. I'll let someone else remove the topcrash blocks relation if that can't be this bug (because the patch for bug 471214 didn't hit the branch(es) for which that topcrash was reported). /be
Blocks: 471214
![]() |
||
Comment 13•15 years ago
|
||
(In reply to comment #8) > If it's getting hard to reduce, don't sweat it further for now. I can probably > debug the cases you have so far. > > But one thing I'm curious about is exactly how you repro this yourself. I tried > the 115-line test case earlier today and it did not crash right away, but it > did crash after I clicked Refresh about 30 times. Is it the same for you or can > you get it to crash with no or fewer reloads? I put in a "for" loop that loops through the whole javascript about 1,000 iterations, but I guess I forgot to put that in, and in my (limited) standalone testing it crashed both times, so I think I got lucky..
Assignee | ||
Comment 14•15 years ago
|
||
Attachment #407323 -
Flags: review?(gal)
Comment 15•15 years ago
|
||
Comment on attachment 407323 [details] [diff] [review] Patch Stealing, this was my fault. /be
Attachment #407323 -
Flags: review?(gal) → review+
Updated•15 years ago
|
Attachment #407323 -
Flags: review+
Comment 16•15 years ago
|
||
Looks like this is not the top crash though since the regressing patch is not on 1.9.1 or 1.9.2.
Assignee | ||
Comment 17•15 years ago
|
||
Pushed to m-c as 0facea043ada. Test case is js/src/trace-test/tests/basic/bug522817.js
Comment 18•15 years ago
|
||
dmandelin, thanks! but don' forget in-testsuite+ when you check in a test.
Flags: in-testsuite+
Updated•15 years ago
|
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Comment 19•15 years ago
|
||
I will try not to add bugs that look like topcrashes, 100x on the blackboard. /be
Assignee | ||
Updated•15 years ago
|
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•