Closed
Bug 324043
Opened 19 years ago
Closed 19 years ago
Loop in prototype chain when running with WAY_TOO_MUCH_GC
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 307317
People
(Reporter: bzbarsky, Unassigned)
References
Details
BUILD: MOZILLA_1_8_0_BRANCH current Firefox and MOZILLA_1_8_BRANCH current Seamonkey and Firefox (probably also MOZILLA_1_8_0_BRANCH current Seamonkey, but I didn't test) STEPS TO REPRODUCE: 1) Compile with WAY_TOO_MUCH_GC defined in jsgc.h 2) Start the browser EXPECTED RESULTS: Browser starts. ACTUAL RESULTS: 100% CPU infinite loop. DETAILS: We're in an infinite loop with the following stack: #0 0xb7f98d1f in js_LookupPropertyWithFlags (cx=0x8127c88, obj=0x8122c18, id=135478584, flags=16, objp=0xbfffe298, propp=0xbfffe294) at ../../../mozilla/js/src/jsobj.c:2646 #1 0xb7f9766e in js_FindConstructor (cx=0x8127c88, start=0x0, name=0xb79bd88c "XPCNativeWrapper", vp=0xbfffe2e0) at ../../../mozilla/js/src/jsobj.c:2104 #2 0xb7f9d245 in GetClassPrototype (cx=0x8127c88, scope=0x8122bc8, name=0xb79bd88c "XPCNativeWrapper", protop=0xbfffe368) at ../../../mozilla/js/src/jsobj.c:3837 #3 0xb7f96fd7 in js_NewObject (cx=0x8127c88, clasp=0xb79c2ba0, proto=0x0, parent=0x8122bc8) at ../../../mozilla/js/src/jsobj.c:1985 #4 0xb7f36fdf in JS_InitClass (cx=0x8127c88, obj=0x8122bc8, parent_proto=0x0, clasp=0xb79c2ba0, constructor=0xb79abb82 <XPCNativeWrapperCtor>, nargs=0, ps=0x0, fs=0xb79c2c08, static_ps=0x0, static_fs=0x0) at ../../../mozilla/js/src/jsapi.c:2014 #5 0xb79ac66f in XPCNativeWrapper::AttachNewConstructorObject (ccx=@0xbfffe430, aGlobalObject=0x8122bc8) at ../../../../../mozilla/js/src/xpconnect/src/XPCNativeWrapper.cpp:1313 #6 0xb7953234 in nsXPConnect::InitClasses (this=0x81264b0, aJSContext=0x8127c88, aGlobalJSObj=0x8122bc8) at ../../../../../mozilla/js/src/xpconnect/src/nsXPConnect.cpp:451 #7 0xb798841e in XPCJSContextStack::GetSafeJSContext (this=0x8126468, aSafeJSContext=0xbfffe56c) at ../../../../../mozilla/js/src/xpconnect/src/xpcthreadcontext.cpp:158 #8 0xb7988c9f in nsXPCThreadJSContextStackImpl::GetSafeJSContext (this=0x81263b8, aSafeJSContext=0xbfffe56c) at ../../../../../mozilla/js/src/xpconnect/src/xpcthreadcontext.cpp:333 #9 0xb752224d in nsScriptSecurityManager::GetSafeJSContext (this=0x81261b8) at ../../../mozilla/caps/src/nsScriptSecurityManager.cpp:236 #10 0xb752b9ed in nsScriptSecurityManager::Init (this=0x81261b8) at ../../../mozilla/caps/src/nsScriptSecurityManager.cpp:2935 #11 0xb752c26e in nsScriptSecurityManager::GetScriptSecurityManager () at ../../../mozilla/caps/src/nsScriptSecurityManager.cpp:3017 #12 0xb7536251 in Construct_nsIScriptSecurityManager (aOuter=0x0, aIID=@0xb79b5780, aResult=0xbfffe6d0) at ../../../mozilla/caps/src/nsSecurityManagerFactory.cpp:357 #13 0xb7e3d0bf in nsGenericFactory::CreateInstance (this=0x81261a0, aOuter=0x0, aIID=@0xb79b5780, aResult=0xbfffe6d0) at nsGenericFactory.cpp:79 #14 0xb7ea867d in nsComponentManagerImpl::CreateInstanceByContractID (this=0x809dba0, aContractID=0xb79be400 "@mozilla.org/scriptsecuritymanager;1", aDelegate=0x0, aIID=@0xb79b5780, aResult=0xbfffe6d0) at ../../../mozilla/xpcom/components/nsComponentManager.cpp:1981 #15 0xb7ea9556 in nsComponentManagerImpl::GetServiceByContractID (this=0x809dba0, aContractID=0xb79be400 "@mozilla.org/scriptsecuritymanager;1", aIID=@0xb79b5780, result=0xbfffe780) at ../../../mozilla/xpcom/components/nsComponentManager.cpp:2408 #16 0xb7e38a42 in CallGetService ( aContractID=0xb79be400 "@mozilla.org/scriptsecuritymanager;1", aIID=@0xb79b5780, aResult=0xbfffe780) at nsComponentManagerUtils.cpp:92 #17 0xb7e38ed3 in nsGetServiceByContractID::operator() (this=0xbfffe794, aIID=@0xb79b5780, aInstancePtr=0xbfffe780) at nsComponentManagerUtils.cpp:278 #18 0xb796f0cb in nsCOMPtr<nsIScriptSecurityManager>::assign_from_gs_contractid ( this=0xbfffe7f0, gs= {mContractID = 0xb79be400 "@mozilla.org/scriptsecuritymanager;1"}, aIID=@0xb79b5780) at ../../../../dist/include/xpcom/nsCOMPtr.h:1272 etc. In frame 0 we have: (gdb) frame 0 #0 0xb7f98d1f in js_LookupPropertyWithFlags (cx=0x8127c88, obj=0x8122c18, id=135478584, flags=16, objp=0xbfffe298, propp=0xbfffe294) at ../../../mozilla/js/src/jsobj.c:2646 2646 scope = OBJ_SCOPE(obj); (gdb) p obj $4 = (JSObject *) 0x8122c18 (gdb) p ::JS_GetPrototype(cx, obj) $5 = (JSObject *) 0x8122c58 (gdb) p ::JS_GetPrototype(cx, ::JS_GetPrototype(cx, obj)) $6 = (JSObject *) 0x8122c18 hence the infinite loop, of course. More info: (gdb) set $proto = ::JS_GetPrototype(cx, obj) (gdb) set $protoclass = ::JS_GetClass(cx, $proto) (gdb) set $objclass = ::JS_GetClass(cx, obj) (gdb) p *$protoclass $9 = {name = 0xb7feaf24 "Function", flags = 517, (gdb) p *$objclass $10 = {name = 0xb7feaf24 "Function", flags = 517, Given that there are no asserts firing, shaver's hypothesis is: <shaver> if it's GC related <shaver> then we might have collected an object and reused it <shaver> and then stored a dangling weak pointer to the "old" object This is sorta blocking me trying to reproduce bug, so anything would help (even if it's just something I can apply locally). I can reproduce this 100% reliably, so if you need more debug info from gdb, just catch me on IRC.
Reporter | ||
Comment 1•19 years ago
|
||
Fwiw, this may well be fixed by attachment 195313 [details] [diff] [review]. I'll check tonight.
Depends on: 307317
Reporter | ||
Comment 2•19 years ago
|
||
Yeah, attachment 195313 [details] [diff] [review] fixes this. Now I get regexp issues instead. :( *** This bug has been marked as a duplicate of 307317 ***
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•