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)

1.8 Branch
x86
Linux
defect
Not set
major

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.
Fwiw, this may well be fixed by attachment 195313 [details] [diff] [review].  I'll check tonight.
Depends on: 307317
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
No longer blocks: 322722
You need to log in before you can comment on or make changes to this bug.