Assertion failure: from <= commitEnd_

RESOLVED FIXED in mozilla8

Status

()

Core
JavaScript Engine
--
critical
RESOLVED FIXED
6 years ago
4 years ago

People

(Reporter: bc, Assigned: luke)

Tracking

(Blocks: 1 bug, {assertion, testcase})

Trunk
mozilla8
x86
Windows XP
assertion, testcase
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox6 affected, firefox7 affected, firefox8 affected)

Details

(Whiteboard: js-triage-done, URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

6 years ago
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.
(Assignee)

Comment 1

6 years ago
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.
Whiteboard: js-triage-needed
(Assignee)

Updated

6 years ago
Assignee: general → luke
Whiteboard: js-triage-needed → js-triage-done
(Reporter)

Comment 2

6 years ago
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.
(Assignee)

Comment 3

6 years ago
Great, thanks.  I just loaded the page on a debug Win7 build (with lots of RAM) and was not able to repro.
(Assignee)

Comment 4

6 years ago
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 :)
(Reporter)

Comment 5

6 years ago
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 *
(Reporter)

Updated

6 years ago
Keywords: testcase-wanted → testcase
(Assignee)

Comment 6

6 years ago
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?
(Assignee)

Comment 7

6 years ago
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.
(Assignee)

Comment 8

6 years ago
Wow, I tried your reduced testcase on Win7 and it does indeed assert; incredible reduction!
(Assignee)

Comment 9

6 years ago
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.
Attachment #547708 - Attachment is obsolete: true
Attachment #547716 - Flags: review?(dvander)
Comment on attachment 547716 [details] [diff] [review]
real fix now

Review of attachment 547716 [details] [diff] [review]:
-----------------------------------------------------------------
Attachment #547716 - Flags: review?(dvander) → review+
http://hg.mozilla.org/mozilla-central/rev/4c3f6e99461e
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla8
A testcase for this bug was automatically identified at js/src/jit-test/tests/basic/testBug673068.js.
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.