Closed Bug 307279 Opened 20 years ago Closed 20 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
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: 20 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: