Closed Bug 307279 Opened 19 years ago Closed 19 years ago

[FIX]Classinfo doesn't protect newly-wrapped stuff from GC

Categories

(Core :: DOM: Core & HTML, defect, P1)

x86
Linux
defect

Tracking

()

RESOLVED FIXED
mozilla1.8beta4

People

(Reporter: bzbarsky, Assigned: bzbarsky)

Details

(Keywords: fixed1.8)

Attachments

(1 file)

nsDOMClassInfo::WrapNative just returns the jsval, not the
nsIXPConnectJSObjectHolder.  This means that if the caller happens to GC the
jsval could die.  And JS_DefineUCProperty can GC (if it atomizes the prop name).

So I think that nsDOMClassInfo::WrapNative should just return the
nsIXPConnectJSObjectHolder too.  Or we could make it an optional arg and callers
who know they don't need it (getter hooks) can pass nsnull for the
nsIXPConnectJSObjectHolder** if that would be better... but I think having it
explicitly there reduces the chance of mistakes
Attached patch PatchSplinter Review
The nsWindowSH::NewResolve change is not strictly for this bug, but it's just a
silly (regression) mistake with a code line ending up as part of a comment when
it shouldn't be.
Attachment #195077 - Flags: superreview?(brendan)
Attachment #195077 - Flags: review?(jst)
Priority: -- → P1
Target Milestone: --- → mozilla1.8beta4
Comment on attachment 195077 [details] [diff] [review]
Patch

r=jst
Attachment #195077 - Flags: review?(jst) → review+
Comment on attachment 195077 [details] [diff] [review]
Patch

Up to jst on whether to have a default null for aHolder, but I would -- matter
of taste, mostly, but it also reduces call side code bloat, from the look of
things.  I *trust* the few top hackers operating here to remember when to pass
a holder!

(Don't break my heard! ;-)

Approving for 1.8b4 -- this is a safe fix, and we want that *objp = obj; line
that was badly joined into the preceding comment line!

/be
Attachment #195077 - Flags: superreview?(brendan)
Attachment #195077 - Flags: superreview+
Attachment #195077 - Flags: approval1.8b4+
Fixed trunk and branch
Status: NEW → RESOLVED
Closed: 19 years ago
Keywords: fixed1.8
Resolution: --- → FIXED
did this break the mac build on the trunk?

Normally I wouldn't care so much but it just landed on the branch too and I'm
busy trying to fix the Mac bustage due to enabling official branding on the
release machines and that will be made more difficult if the mac build starts
breaking here :)
I forgot to check in the .h part of the patch.  It's in now.
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: