I'm afraid I don't know much about this aspect of the code, but maybe someone on the JS engine mailing list can help. Unfortunately, there isn't any easy way to track down GC issues.
-Bill ----- Original Message ----- > From: "Norbert Lindenberg" <[email protected]> > To: "William McCloskey" <[email protected]> > Cc: "Norbert Lindenberg" <[email protected]>, "Till > Schneidereit" <[email protected]>, "Luke > Wagner" <[email protected]> > Sent: Tuesday, September 25, 2012 2:13:06 PM > Subject: Re: Need help with crashes > > I spent some more time trying to track down which parts of my code > are involved in this crash. It seems it's the use of normal class > creation mechanisms for constructors that are not properties of the > global object. > > In the Internationalization API, the Intl object is a property of the > global object, and has three constructor properties: Intl.Collator, > Intl.NumberFormat, Intl.DateTimeFormat. In the crashing version of > the code, I have all four created as properties of the global > object, using the JS_PROTO macro and additions to > GlobalObject::initStandardClasses. I then use the following code to > remove the constructors from the global object and add them to Intl: > > JSBool > js_MoveConstructor(JSContext *cx, HandleObject obj, > HandleObject Intl, const char *constructorName) > { > Value constructor; > if (!JS_GetProperty(cx, obj, constructorName, &constructor) || > constructor == JSVAL_VOID) { > return false; > } > if (!JS_DefineProperty(cx, Intl, constructorName, constructor, > NULL, NULL, 0)) { > return false; > } > if (!JS_DeleteProperty(cx, obj, constructorName)) { > return false; > } > return true; > } > > It seems that calling this function for Collator, NumberFormat, and > DateTimeFormat is what triggers the crash. > > Are there assumptions in the cycle collector that objects created via > GlobalObject::initStandardClasses remain properties of the global > object? Is that a good assumption to make? > > One important thing that this initialization does is to add the > constructors and their properties to slots of the global object, > which I need so that I can implement spec language such as "standard > built-in object that is the initial value of Intl.DateTimeFormat". > > I found a different way to create my objects and register them in the > slots of the global object (in the section for one-off properties > such as SET_ITERATOR_PROTO), but it's a lot of additional code and > seems more fragile. > > Thanks, > Norbert > > > On Sep 4, 2012, at 9:17 , Luke Wagner wrote: > > > The former crash is in the cycle collector (which doesn't run in > > shell builds). Any idea of common causes for that Bill? > > > > ----- Original Message ----- > >> Hi Luke and Till, > >> > >> Would you be willing to help me track down the cause of crashes > >> that > >> I'm seeing in Firefox? I've tried to follow all the hints I could > >> glean from the SpiderMonkey garbage collection documentation > >> (which > >> I find terribly disorganized), with no real progress. > >> > >> I could use two kinds of assistance: > >> > >> - A review of the C++ code within the intl.patch that's attached > >> to > >> bug 769872 with an eye towards possibly crash-inducing mistakes > >> (other feedback welcome as well). > >> > >> - Tips on how SpiderMonkey pros track down bugs related to garbage > >> collection. > >> > >> Here's the current situation: > >> > >> I'm testing with the ECMAScript Internationalization API > >> conformance > >> test suite (hg.ecmascript.org/tests/test262, intl402 subset). If > >> you'd like to follow and test with the js shell, download the test > >> suite, then build the console tests, and run: > >> > >> $ hg clone http://hg.ecmascript.org/tests/test262 test262 > >> $ cd test262/tools/packaging > >> $ python packager.py --console ES5.1 > >> $ cd ../.. > >> $ python tools/packaging/test262.py --command > >> <path-into-your-mozilla-build>/js intl402 > >> > >> To test with a Firefox build, point it directly at the > >> test262/website/testcases_intl402.html file, click the Run tab, > >> then > >> the green Run All button. You could also try going to > >> http://test262.ecmascript.org/testcases_intl402.html. > >> > >> In my experience, everything works fine when testing a normal > >> debug > >> build with the js shell - there are test failures (about 27 out of > >> the 137 tests), but no crashes. > >> > >> Firefox on the other hand will crash sooner or later - sooner > >> could > >> mean before it even opens a window, later sometime during the test > >> suite. > >> > >> GDB usually shows me something like this: > >> > >> (gdb) bt > >> #0 0x000000010442ef42 in js::ObjectImpl::markChildren > >> (this=0x11601f060, > >> trc=0x10a380870) > >> at > >> /Users/standards/Mozilla/self-hosted/js/src/vm/ObjectImpl.cpp:285 > >> #1 0x00000001044e2148 in js::gc::MarkChildren (trc=0x10a380870, > >> obj=0x11601f060) > >> at > >> /Users/standards/Mozilla/self-hosted/js/src/gc/Marking.cpp:763 > >> #2 0x00000001044e30c9 in js::TraceChildren (trc=0x10a380870, > >> thing=0x11601f060, kind=JSTRACE_OBJECT) > >> at > >> /Users/standards/Mozilla/self-hosted/js/src/gc/Marking.cpp:1287 > >> #3 0x00000001041432c3 in JS_TraceChildren (trc=0x10a380870, > >> thing=0x11601f060, kind=JSTRACE_OBJECT) > >> at /Users/standards/Mozilla/self-hosted/js/src/jsapi.cpp:2570 > >> #4 0x00000001028bcc9a in NoteGCThingJSChildren (rt=0x10bb98000, > >> p=0x11601f060, traceKind=JSTRACE_OBJECT, cb=@0x10a380ad8) > >> at > >> > >> /Users/standards/Mozilla/self-hosted/js/xpconnect/src/nsXPConnect.cpp:817 > >> #5 0x00000001028b3ef9 in TraverseGCThing (ts=TRAVERSE_FULL, > >> p=0x11601f060, > >> traceKind=JSTRACE_OBJECT, cb=@0x10a380ad8) > >> at > >> > >> /Users/standards/Mozilla/self-hosted/js/xpconnect/src/nsXPConnect.cpp:879 > >> #6 0x00000001028b38e9 in nsXPConnectParticipant::TraverseImpl ( > >> that=0x105884938, p=0x11601f060, cb=@0x10a380ad8) > >> at > >> > >> /Users/standards/Mozilla/self-hosted/js/xpconnect/src/nsXPConnect.cpp:892 > >> #7 0x0000000101ac6e8e in nsCycleCollectionParticipant::Traverse ( > >> this=0x105884938, p=0x11601f060, cb=@0x10a380ad8) > >> at nsCycleCollectionParticipant.h:254 > >> #8 0x0000000103548eaf in GCGraphBuilder::Traverse > >> (this=0x10a380ad8, > >> aPtrInfo=0x11b0b1b88) > >> at > >> > >> /Users/standards/Mozilla/self-hosted/xpcom/base/nsCycleCollector.cpp:1723 > >> #9 0x0000000103549e56 in nsCycleCollector::MarkRoots > >> (this=0x10a242000, > >> builder=@0x10a380ad8) > >> at > >> > >> /Users/standards/Mozilla/self-hosted/xpcom/base/nsCycleCollector.cpp:2037 > >> #10 0x000000010354af74 in nsCycleCollector::BeginCollection > >> (this=0x10a242000, > >> aMergeCompartments=false, aListener=0x0) > >> at > >> > >> /Users/standards/Mozilla/self-hosted/xpcom/base/nsCycleCollector.cpp:2681 > >> #11 0x00000001035501b3 in nsCycleCollectorRunner::Run > >> (this=0x100411740) > >> at > >> > >> /Users/standards/Mozilla/self-hosted/xpcom/base/nsCycleCollector.cpp:2961 > >> #12 0x000000010352b5bd in nsThread::ProcessNextEvent > >> (this=0x100470c40, > >> mayWait=true, result=0x10a380dde) > >> at > >> /Users/standards/Mozilla/self-hosted/xpcom/threads/nsThread.cpp:624 > >> #13 0x000000010349b7af in NS_ProcessNextEvent_P > >> (thread=0x100470c40, > >> mayWait=true) at nsThreadUtils.cpp:220 > >> #14 0x000000010352a1a7 in nsThread::ThreadFunc (arg=0x100470c40) > >> at > >> /Users/standards/Mozilla/self-hosted/xpcom/threads/nsThread.cpp:257 > >> #15 0x00000001005386b3 in _pt_root (arg=0x10046bc50) > >> at > >> > >> /Users/standards/Mozilla/self-hosted/nsprpub/pr/src/pthreads/ptthread.c:156 > >> #16 0x00007fff8faa58bf in _pthread_start () > >> #17 0x00007fff8faa8b75 in thread_start () > >> > >> I enabled zealous GC, and the attached gctests.patch tried to > >> force > >> GC directly in my own functions that might do something wrong. The > >> result was that I crashed sooner, but gdb "thread apply all bt" > >> never showed any of my functions active at the time of the crash. > >> The patch also has some changes in Till's code that I thought > >> might > >> improve things, but that didn't stop the crashes. > >> > >> Separately, I tried the rooting verification mode > >> https://developer.mozilla.org/en-US/docs/SpiderMonkey/Internals/Garbage_collection#Rooting_verification_mode > >> With this I got a crash while running just a simple statement in > >> the > >> js shell: > >> > >> js> new Intl.DateTimeFormat().format(new Date()) > >> > >> Program received signal EXC_BAD_ACCESS, Could not access memory. > >> Reason: KERN_INVALID_ADDRESS at address: 0x00000001daf150e8 > >> js::EncapsulatedPtr<js::Shape, unsigned long>::pre > >> (this=0x1daf150e8) > >> at Barrier.h:175 > >> 175 void pre() { T::writeBarrierPre(value); } > >> (gdb) bt > >> #0 js::EncapsulatedPtr<js::Shape, unsigned long>::pre > >> (this=0x1daf150e8) > >> at Barrier.h:175 > >> #1 0x00000001002384d0 in js::HeapPtr<js::Shape, unsigned > >> long>::operator= ( > >> this=0x1daf150e8, v=0x101f21060) at Barrier.h:194 > >> #2 0x000000010022f30f in js::Bindings::initWithTemporaryStorage ( > >> this=0x1daf150e8, cx=0x100d15870, numArgs=0, numVars=0, > >> bindingArray=0x0) > >> at jsscript.cpp:93 > >> #3 0x000000010035c56c in js::frontend::CompileScript > >> (cx=0x100d15870, > >> scopeChain= > >> {<JS::HandleBase<JSObject *>> = {<No data fields>}, ptr = > >> 0x7fff5fbff5a0}, callerFrame=0x0, options=@0x7fff5fbff4e0, > >> chars=0x100d215f0, length=44, > >> source_=0x0, staticLevel=0) > >> at > >> > >> /Users/standards/Mozilla/self-hosted/js/src/frontend/BytecodeCompiler.cpp:117 > >> #4 0x00000001000688e2 in JS::Compile (cx=0x100d15870, obj= > >> {<JS::HandleBase<JSObject *>> = {<No data fields>}, ptr = > >> 0x7fff5fbff5a0}, options= > >> {principals = 0x0, originPrincipals = 0x0, version = > >> JSVERSION_ECMA_5, versionSet = false, utf8 = false, filename > >> = > >> 0x1005379f7 "typein", lineno = 1, compileAndGo = true, > >> noScriptRval = false, selfHostingMode = false, sourcePolicy = > >> JS::CompileOptions::SAVE_SOURCE}, chars=0x100d215f0, > >> length=44) > >> at jsapi.cpp:5222 > >> #5 0x00000001000692ca in JS_CompileUCScript (cx=0x100d15870, > >> objArg=0x1daf11060, chars=0x100d215f0, length=44, > >> filename=0x1005379f7 "typein", lineno=1) at jsapi.cpp:5319 > >> #6 0x000000010000b113 in Process (cx=0x100d15870, > >> obj_=0x1daf11060, > >> filename=0x0, forceTTY=true) at js.cpp:532 > >> #7 0x0000000100009634 in ProcessArgs (cx=0x100d15870, > >> obj_=0x1daf11060, > >> op=0x7fff5fbff9d8) at js.cpp:4714 > >> #8 0x0000000100008f4f in Shell (cx=0x100d15870, > >> op=0x7fff5fbff9d8, > >> envp=0x7fff5fbffb00) at js.cpp:4775 > >> #9 0x0000000100009ffb in main (argc=1, argv=0x7fff5fbffaf0, > >> envp=0x7fff5fbffb00) at js.cpp:4950 > >> > >> Are the bindings gcthings that need to be rooted? > >> > >> Thanks, > >> Norbert > >> > >> > >> > > _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
