340751 - ecma_3/Array/regress-322135-01.js: result: CRASHED type: browser

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Bob Clary [:bc] (inactive)]

Bug 322135 is not fixed, but the crash (JS_Assert) is a recent (since 20060527) regression. Found with 20060606 win/macppc/linux builds.

#ifdef JS_THREADSAFE
            /*
             * Refill the local free list by taking free things from the last
             * arena. Prefer to order free things by ascending address in the
             * (unscientific) hope of better cache locality.
             */
=>            JS_ASSERT(!flbase[flindex]);
            METER(nfree = 0);
     

 	ntdll.dll!_DbgBreakPoint@0() 	
 	js3250.dll!JS_Assert(const char * s=0x0052c7ac, const char * file=0x0052c774, int ln=932)  Line 62	C
>	js3250.dll!js_NewGCThing(JSContext * cx=0x0412a900, unsigned int flags=1, unsigned int nbytes=8)  Line 932 + 0x22 bytes	C
 	js3250.dll!js_NewString(JSContext * cx=0x0412a900, unsigned short * chars=0x3cad1370, unsigned int length=10, unsigned int gcflag=0)  Line 2437 + 0x12 bytes	C
 	js3250.dll!JS_NewStringCopyZ(JSContext * cx=0x0412a900, const char * s=0x0012ea76)  Line 4455 + 0x13 bytes	C
 	js3250.dll!js_NumberToString(JSContext * cx=0x0412a900, double d=4291922632.0000000)  Line 716 + 0xd bytes	C
 	js3250.dll!IndexToId(JSContext * cx=0x0412a900, unsigned long index=4291922632, long * idp=0x0012eae0)  Line 209 + 0x1f bytes	C
 	js3250.dll!array_length_setter(JSContext * cx=0x0412a900, JSObject * obj=0x042c2838, long id=12424636, long * vp=0x0012ebe8)  Line 321 + 0x11 bytes	C
 	js3250.dll!js_SetProperty(JSContext * cx=0x0412a900, JSObject * obj=0x042c2838, long id=12440040, long * vp=0x0012ebe8)  Line 3378 + 0x151 bytes	C
 	js3250.dll!js_SetLengthProperty(JSContext * cx=0x0412a900, JSObject * obj=0x042c2838, unsigned long length=0)  Line 262 + 0x1d bytes	C
 	js3250.dll!array_push(JSContext * cx=0x0412a900, JSObject * obj=0x042c2838, unsigned int argc=1, long * argv=0x044dc248, long * rval=0x0012eca0)  Line 1096 + 0x11 bytes	C
 	js3250.dll!js_Invoke(JSContext * cx=0x0412a900, unsigned int argc=1, unsigned int flags=0)  Line 1328 + 0x20 bytes	C
 	js3250.dll!js_Interpret(JSContext * cx=0x0412a900, unsigned char * pc=0x044d3223, long * result=0x0012f73c)  Line 4017 + 0xf bytes	C
 	js3250.dll!js_Execute(JSContext * cx=0x0412a900, JSObject * chain=0x04271f88, JSScript * script=0x044d3160, JSStackFrame * down=0x00000000, unsigned int flags=0, long * result=0x0012f84c)  Line 1573 + 0x13 bytes	C
 	js3250.dll!JS_EvaluateUCScriptForPrincipals(JSContext * cx=0x0412a900, JSObject * obj=0x04271f88, JSPrincipals * principals=0x038171bc, const unsigned short * chars=0x044c3030, unsigned int length=2620, const char * filename=0x0449e510, unsigned int lineno=1, long * rval=0x0012f84c)  Line 4292 + 0x19 bytes	C
 	gklayout.dll!nsJSContext::EvaluateString(const nsAString_internal & aScript={...}, void * aScopeObject=0x04271f88, nsIPrincipal * aPrincipal=0x038171b8, const char * aURL=0x0449e510, unsigned int aLineNo=1, const char * aVersion=0x00508fd4, nsAString_internal * aRetValue=0x00000000, int * aIsUndefined=0x0012f92c)  Line 1076 + 0x43 bytes	C++
 	gklayout.dll!nsScriptLoader::EvaluateScript(nsScriptLoadRequest * aRequest=0x0449d2c0, const nsString & aScript={...})  Line 756 + 0x62 bytes	C++
 	gklayout.dll!nsScriptLoader::ProcessRequest(nsScriptLoadRequest * aRequest=0x0449d2c0)  Line 661 + 0x13 bytes	C++
 	gklayout.dll!nsScriptLoader::OnStreamComplete(nsIStreamLoader * aLoader=0x0449e5f8, nsISupports * aContext=0x0449d2c0, unsigned int aStatus=0, unsigned int stringLen=2620, const unsigned char * string=0x044d6508)  Line 1018	C++
 	necko.dll!nsStreamLoader::OnStopRequest(nsIRequest * request=0x044d0210, nsISupports * ctxt=0x0449d2c0, unsigned int aStatus=0)  Line 117	C++
 	necko.dll!nsStreamListenerTee::OnStopRequest(nsIRequest * request=0x044d0210, nsISupports * context=0x0449d2c0, unsigned int status=0)  Line 66	C++
 	necko.dll!nsHttpChannel::OnStopRequest(nsIRequest * request=0x044da0a8, nsISupports * ctxt=0x00000000, unsigned int status=0)  Line 4044	C++
 	necko.dll!nsInputStreamPump::OnStateStop()  Line 567	C++
 	necko.dll!nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream * stream=0x044a6de8)  Line 391 + 0xb bytes	C++
 	xpcom_core.dll!nsInputStreamReadyEvent::Run()  Line 112	C++
 	xpcom_core.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x0012fc34)  Line 483	C++
 	xpcom_core.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x00b39620, int mayWait=1)  Line 225 + 0x16 bytes	C++
 	gkwidget.dll!nsBaseAppShell::Run()  Line 153 + 0xc bytes	C++
 	tkitcmps.dll!nsAppStartup::Run()  Line 171 + 0x1c bytes	C++
 	xul.dll!XRE_main(int argc=3, char * * argv=0x00b38180, const nsXREAppData * aAppData=0x004036b0)  Line 2343 + 0x25 bytes	C++
 	firefox.exe!main(int argc=3, char * * argv=0x00b38180)  Line 61 + 0x13 bytes	C++
 	firefox.exe!__tmainCRTStartup()  Line 586 + 0x19 bytes	C
 	firefox.exe!mainCRTStartup()  Line 403	C
 	kernel32.dll!_BaseProcessStart@4()  + 0x23 bytes

Comment 1

[Bob Clary [:bc] (inactive)]

Igor, can you reproduce this and help out? You should be able to reproduce it by following the URL above in a debug trunk build.

Comment 2

[Bob Clary [:bc] (inactive)]

see also bug 317815 comment 10 and bug 318633. Feel free to dupe.

Comment 3

[Bob Clary [:bc] (inactive)]

Also ecma_3/Array/regress-322135-02.js

Comment 4

[Bob Clary [:bc] (inactive)]

and ecma_3/Array/regress-322135-03.js, ecma_3/Array/regress-322135-04.js

Comment 5

[Igor Bukanov]

Attachment: Fix

This is a fallout from fixes for bug 338653. In that bug I changed js_NewGCThing to allocate things from the thread-local list only when gcMaxMallocBytes barrier is not hit. But that invalidated the assumption in the refill stage that the free list must be empty there. So here is a fix for the fix.

Comment 6

[Igor Bukanov]

(In reply to comment #2)
> see also bug 317815 comment 10 and bug 318633. Feel free to dupe.
> 

The assert here is "harmless". Its violation would mean broken code assumtions leading just to a suboptimal behavior later and no crashes and even no memory leaks.

Comment 7

[Bob Clary [:bc] (inactive)]

(In reply to comment #6)

> 
> The assert here is "harmless". Its violation would mean broken code assumtions
> leading just to a suboptimal behavior later and no crashes and even no memory
> leaks.
> 

Should it be removed or changed to a warning ?

Comment 8

[Igor Bukanov]

(In reply to comment #7)
> (In reply to comment #6)
> > 
> > The assert here is "harmless".
> > ...
> 
> Should it be removed or changed to a warning ?

I do not think so: the violated assert means here broken logic in GC code which can have a rather bad consequences and it was just pure lack that it was harmless in this case. So the patch fixes the real cause of the bug while keeping the assert.    

Comment 9

[Igor Bukanov]

I committed the patch from comment 5 to the trunk.

Comment 10

[Bob Clary [:bc] (inactive)]

verified fixed 1.9 windows/mac(ppc|tel)/linux 20060812