Last Comment Bug 673068 - Assertion failure: from <= commitEnd_
: Assertion failure: from <= commitEnd_
Status: RESOLVED FIXED
js-triage-done
: assertion, testcase
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: x86 Windows XP
: -- critical (vote)
: mozilla8
Assigned To: Luke Wagner [:luke]
:
Mentors:
http://www.ennaharonline.com/ar/
Depends on:
Blocks: 532972
  Show dependency treegraph
 
Reported: 2011-07-21 02:19 PDT by Bob Clary [:bc:]
Modified: 2013-01-14 08:37 PST (History)
4 users (show)
choller: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
affected
affected
affected


Attachments
testcase (540 bytes, text/html)
2011-07-22 06:41 PDT, Bob Clary [:bc:]
no flags Details
maybe fix (835 bytes, patch)
2011-07-22 09:04 PDT, Luke Wagner [:luke]
no flags Details | Diff | Splinter Review
real fix now (2.15 KB, patch)
2011-07-22 09:53 PDT, Luke Wagner [:luke]
dvander: review+
Details | Diff | Splinter Review

Description Bob Clary [:bc:] 2011-07-21 02:19:09 PDT
1. http://www.ennaharonline.com/ar/ 
2. Assertion failure: from <= commitEnd_, at c:\work\mozilla\builds\nightly\mozilla\js\src\vm/Stack-inl.h:396

Thread 0 (crashed)
 0  mozjs.dll!JS_Assert [jsutil.cpp : 79 + 0x0]
    eip = 0x0110469a   esp = 0x0012a3f4   ebp = 0x0012a3f4   ebx = 0x0545ffb8
    esi = 0x00000000   edi = 0x05891708   eax = 0x00000000   ecx = 0x5bae99f9
    edx = 0x10313d38   efl = 0x00010202
    Found by: given as instruction pointer in context
 1  mozjs.dll!js::StackSpace::ensureSpace(JSContext *,js::MaybeReportError,js::Value *,int) [Stack-inl.h : 396 + 0x20]
    eip = 0x0100c616   esp = 0x0012a3fc   ebp = 0x0012a40c
    Found by: call frame info
 2  mozjs.dll!js::StackSpace::getStackLimit(JSContext *,js::MaybeReportError) [Stack-inl.h : 410 + 0x19]
    eip = 0x0100c563   esp = 0x0012a414   ebp = 0x0012a434
    Found by: call frame info
 3  mozjs.dll!js::mjit::stubs::HitStackQuota(js::VMFrame &) [InvokeHelpers.cpp : 205 + 0x1d]
    eip = 0x012389d5   esp = 0x0012a43c   ebp = 0x0012a448
    Found by: call frame info
 4  mozjs.dll!js::mjit::EnterMethodJIT(JSContext *,js::StackFrame *,void *,js::Value *) [MethodJIT.cpp : 686 + 0x14]
    eip = 0x011ba97b   esp = 0x0012a490   ebp = 0x0012a488
    Found by: call frame info with scanning


So far reproduced on Beta/6, Aurora/7, Nightly/8 on WinXP but with a system of only 1G ram. It may be all OS and just depend on a low memory machine.

I've captured the content and am working on reducing it to a testcase.
Comment 1 Luke Wagner [:luke] 2011-07-21 08:45:39 PDT
If you are able to get this under a debugger, from frame 1, can you print: from, nvals, this->base_, this->conservativeEnd_, this->commitEnd_, this->defaultEnd_, this->trustedEnd_?

I'll try to get a debug build for Win7.
Comment 2 Bob Clary [:bc:] 2011-07-21 10:57:13 PDT
Luke, I'm in the middle of a reduction session on the vm where I can reduce this. I'll catch it in a debugger when that finishes but it'll be a while longer.
Comment 3 Luke Wagner [:luke] 2011-07-21 11:07:17 PDT
Great, thanks.  I just loaded the page on a debug Win7 build (with lots of RAM) and was not able to repro.
Comment 4 Luke Wagner [:luke] 2011-07-21 17:53:43 PDT
Ah, idea: this might be innocuous -- the OOL_STUBCALL adds nfixed to the stack frame to set regs.sp.  Unless I'm missing something, this could put regs.sp (harmlessly) above commitEnd_.  Debug values from comment 1 would help confirm this.  Or I'll write a patch tomorrow and see if it fixes it :)
Comment 5 Bob Clary [:bc:] 2011-07-22 06:41:16 PDT
Created attachment 547678 [details]
testcase

-		from	0x04ec0008 {data={...} }	js::Value *
		nvals	10	int

-		this	0x044aa860 {seg_=0x04d60000 base_=0x04d60000 conservativeEnd_=0x04ec0000 ...}	const js::StackSpace * const
+		seg_	0x04d60000 {prevInContext_=0x00000000 prevInMemory_=0x00000000 regs_=0x0012b604 ...}	js::StackSegment *
-		base_	0x04d60000 {data={...} }	js::Value *
-		data	{asBits=0 s={...} asDouble=0.00000000000000000 ...}	jsval_layout
		asBits	0	unsigned __int64
-		s	{payload={...} tag=0 }	jsval_layout::<unnamed-tag>
-		payload	{i32=0 u32=0 boo=0 ...}	jsval_layout::<unnamed-tag>::<unnamed-tag>
		i32	0	int
		u32	0	unsigned int
		boo	0	int
+		str	0x00000000 {d={...} }	JSString *
+		obj	0x00000000 {lastProp=??? clasp=??? flags=??? ...}	JSObject *
		ptr	0x00000000	void *
		why	JS_ARRAY_HOLE	JSWhyMagic
		word	0	unsigned int
		tag	0	JSValueTag
		asDouble	0.00000000000000000	double
		asPtr	0x00000000	void *
-		conservativeEnd_	0x04ec0000 {data={...} }	js::Value *
-		data	{asBits=??? s={...} asDouble=??? ...}	jsval_layout
		asBits	CXX0030: Error: expression cannot be evaluated	
+		s	{payload={...} tag=??? }	jsval_layout::<unnamed-tag>
		asDouble	CXX0030: Error: expression cannot be evaluated	
		asPtr	CXX0030: Error: expression cannot be evaluated	
-		commitEnd_	0x04ec0000 {data={...} }	js::Value *
-		data	{asBits=??? s={...} asDouble=??? ...}	jsval_layout
		asBits	CXX0030: Error: expression cannot be evaluated	
+		s	{payload={...} tag=??? }	jsval_layout::<unnamed-tag>
		asDouble	CXX0030: Error: expression cannot be evaluated	
		asPtr	CXX0030: Error: expression cannot be evaluated	
-		defaultEnd_	0x05140000 {data={...} }	js::Value *
-		data	{asBits=??? s={...} asDouble=??? ...}	jsval_layout
		asBits	CXX0030: Error: expression cannot be evaluated	
+		s	{payload={...} tag=??? }	jsval_layout::<unnamed-tag>
		asDouble	CXX0030: Error: expression cannot be evaluated	
		asPtr	CXX0030: Error: expression cannot be evaluated	
-		trustedEnd_	0x05160000 {data={...} }	js::Value *
-		data	{asBits=12894362189 s={...} asDouble=6.370661382619e-314#DEN ...}	jsval_layout
		asBits	12894362189	unsigned __int64
+		s	{payload={...} tag=3 }	jsval_layout::<unnamed-tag>
		asDouble	6.370661382619e-314#DEN	double
		asPtr	0x00905a4d	void *
Comment 6 Luke Wagner [:luke] 2011-07-22 09:04:50 PDT
Created attachment 547708 [details] [diff] [review]
maybe fix

Thanks for all the help.  Yes, it looks like 'from' is just off by 1 slot.  I see a debug-only bug in StackSpace::getStackLimit that could cause this if regs.fp()->script->nfixed > 0.  Would you be able to try this patch?
Comment 7 Luke Wagner [:luke] 2011-07-22 09:09:17 PDT
Oh wait, that patch is going to fail the JS_ASSERT(from >= firstUnused()) assert.  Basically, regs.sp under HitStackQuota is an innocuous lie here and the assertions are catch this.
Comment 8 Luke Wagner [:luke] 2011-07-22 09:14:00 PDT
Wow, I tried your reduced testcase on Win7 and it does indeed assert; incredible reduction!
Comment 9 Luke Wagner [:luke] 2011-07-22 09:53:12 PDT
Created attachment 547716 [details] [diff] [review]
real fix now

Reproducible test-case in hand I confirmed that indeed script->nfixed > 0 and this is the cause.  Knowing this, there is a surprisingly simple shell testcase.  Again, IIUC, this is only a matter of assertions, I don't see a crash.
Comment 10 David Anderson [:dvander] 2011-07-25 11:55:23 PDT
Comment on attachment 547716 [details] [diff] [review]
real fix now

Review of attachment 547716 [details] [diff] [review]:
-----------------------------------------------------------------
Comment 11 Marco Bonardo [::mak] (Away 6-20 Aug) 2011-07-26 03:59:29 PDT
http://hg.mozilla.org/mozilla-central/rev/4c3f6e99461e
Comment 12 Christian Holler (:decoder) 2013-01-14 08:37:00 PST
A testcase for this bug was automatically identified at js/src/jit-test/tests/basic/testBug673068.js.

Note You need to log in before you can comment on or make changes to this bug.