son of bug 279289 (yes, i do have brendan's fix for that bug in this build, and yes i removed my patch for that bug). of interest, gJsds->mPauseLevel is now at the time of my crash 0x14, it was 0x16 when i broke in to investigate bug 293946. after filing that bug, i continued and dismissed a couple of the slow script dialogs (i believe i had just dismissed the third one when this crash happened). i will attach a file with the full stack from the previous bug, output from analyze and the full stack for the time of this crash. some locals from DefineUCProperty: name "_mStrBundle" namelen 0xb getter 0x0 setter 0x0 attrs 1 flags 1 tinyid 0 atom 0x03445048 = cx->lastAtom cx->newborn[0..15] = 0x0 -obj 0x06fcc7d8 |- map 0x06fcc7f8 || nrefs 0x06fcc8f0 ||- ops 0x06fcb687 <- ODD!! ||| newObjectMap 0x00200020 ||| destroyObjectMap 0x01202000 ||| lookupProperty 0x01000000 ||| defineProperty 0x00200000 ||| getProperty 0x20002002 ||| setProperty 0x00202020 ||| getAttributes 0x20012020 ||| setAttributes 0x20202020 ||| deleteProperty 0x20202020 ||| defaultValue 0x20202020 ||| enumerate 0x20202020 ||| checkAccess 0x20202020 ||| thisObject 0x20202020 ||| dropProperty 0x20202020 ||| call 0x20202020 ||| construct 0x20202020 ||| xdrObject 0x20202020 ||| hasInstance 0x20202020 ||| setProto 0x20202020 ||| setParent 0x20202020 ||| mark 0x20202020 ||| clear 0x20202020 ||| getRequiredSlot 0x20202020 ||\ setRequiredSlot 0x20202020 || nslots 0x06fcb800 |\ freeslot 0x06fcb688 \ slots 0x06fcb683 cx->runtime->gcBytes 0xdcbc3 gcLastBytes 0xdb6f3 locals from caller (nsXBLProtoImplField::InstallMember): ok 1 result 0 rv 0 for kicks and giggles, the grand caller (nsXBLProtoImpl::InstallImplementation) frame has: targetClassObject 0x06fcc838 targetScriptObject 0x06fcc7d8 <- aka dead obj -this 0x04ce7e50 |mClassName... "chrome://global/content/bindings/dialog.xml#dialog" |-mMembers ||mName "_mStrBundle" ||mFieldText "null" ||mLineNumber 0x21 |\mJSAttributes 1 |mName "_mStrBundle" |-mConstructor ||mJSMethodObject 0x04de2c90 (happy jsobject) |\mIsCompiled 1 \mDestructor 0x0 for my confused reference, the closest xbl bug i can find is bug 292944. i'm currently trying to understand what nsXBLProtoImpl::InitTargetObjects does
So timeless and I did some digging, and we're guessing the problem could be in nsXBLProtoImpl::InitTargetObjects where we do the WrapNative() thing. The nsIXPConnectJSObjectHolder this returns is an XPCWrappedNative, not a XPCJSObjectHolder. The latter roots the JSObject its given while it's alive. The former does not, as far as I can tell (there are comments in there claiming that raising the refcount to two roots the JSObject, but I'm not seeing where that happens; there is no special AddRef impl). What sort of worries me is that I can't find where we _do_ root the JSObject, or at least make other JSObjects point to it....
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P5
Assignee: timeless → nobody
QA Contact: ian → xbl
Crash Signature: [@ DefineUCProperty]
You need to log in before you can comment on or make changes to this bug.