"Assertion failure: sprop->slot < OBJ_SCOPE(object)->freeslot"

VERIFIED FIXED

Status

()

Core
JavaScript Engine
--
critical
VERIFIED FIXED
8 years ago
8 years ago

People

(Reporter: Jesse Ruderman, Assigned: dmandelin)

Tracking

({assertion, testcase})

Trunk
x86
Mac OS X
assertion, testcase
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments, 5 obsolete attachments)

(Reporter)

Description

8 years ago
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)
I got a ~4,000 line testcase coming up soon, still reducing...
Keywords: testcase

Comment 2

8 years ago
Dave, I think this is the top-crasher you were hunting and trying to reproduce.
Created attachment 406943 [details]
3,500-line testcase

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
Created attachment 406987 [details]
~430-line testcase

Still reducing...
Attachment #406943 - Attachment is obsolete: true
Created attachment 407042 [details]
115-line testcase

Almost there...
Attachment #406987 - Attachment is obsolete: true
(Reporter)

Comment 6

8 years ago
Also happens at http://mj12net.org/index.php/system-administrator-interview-cheat-sheet.html
(Reporter)

Updated

8 years ago
Blocks: 519363
Created attachment 407157 [details]
~100-line testcase

That's about all I can manage for today. Jesse, would you like to further reduce this? ;-)
Attachment #407042 - Attachment is obsolete: true
Attachment #407157 - Attachment description: 100-line testcase → ~100-line testcase
(Assignee)

Comment 8

8 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

8 years ago
Created attachment 407182 [details]
decompressed; ~300 lines

(Replaced eval with dump, then pasted into jsbeautifier.)
Attachment #407157 - Attachment is obsolete: true
(Reporter)

Comment 10

8 years ago
Created attachment 407192 [details]
shell testcase, 15 lines
Attachment #407182 - Attachment is obsolete: true
(Assignee)

Comment 11

8 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.
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
(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

8 years ago
Created attachment 407323 [details] [diff] [review]
Patch
Attachment #407323 - Flags: review?(gal)
Comment on attachment 407323 [details] [diff] [review]
Patch

Stealing, this was my fault.

/be
Attachment #407323 - Flags: review?(gal) → review+

Updated

8 years ago
Attachment #407323 - Flags: review+

Comment 16

8 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

8 years ago
Pushed to m-c as 0facea043ada.

Test case is js/src/trace-test/tests/basic/bug522817.js

Comment 18

8 years ago
dmandelin, thanks! but don' forget in-testsuite+ when you check in a test.
Flags: in-testsuite+

Updated

8 years ago
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
I will try not to add bugs that look like topcrashes, 100x on the blackboard.

/be
No longer blocks: 519363
(Assignee)

Updated

8 years ago
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.