xbl crash [@ DefineUCProperty] after continuing from two or three of the slow script dialogs from bug 293946




14 years ago
7 years ago


(Reporter: timeless, Unassigned)


(Depends on: 1 bug, {crash})

Windows XP

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [expired?], crash signature)


(1 attachment)

49.72 KB, application/x-zip-compressed


14 years ago
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"
||mName	"_mStrBundle"
||mFieldText	"null"
||mLineNumber	0x21
|\mJSAttributes	1
|mName	"_mStrBundle"
||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

Comment 1

14 years ago
Created attachment 183466 [details]
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....



13 years ago
Ever confirmed: true
Priority: -- → P5
Assignee: timeless → nobody
QA Contact: ian → xbl
Whiteboard: [expired?]


7 years ago
Crash Signature: [@ DefineUCProperty]
You need to log in before you can comment on or make changes to this bug.