Closed
Bug 328008
Opened 19 years ago
Closed 7 years ago
root before calling JS_SetReservedSlot
Categories
(Core :: XPConnect, defect)
Core
XPConnect
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: dbaron, Unassigned)
References
Details
In bug 307560 comment 6, bz wrote:
> Just looking at other callers of JS_SetReservedSlot, it looks like we may need
> similar protection in:
>
> XPCDispInterface::Member::GetValue (I think we have GC bugs on this one!)
> XPCNativeWrapperCtor
> XPCNativeWrapper::GetNewOrUsed
>
> Followup bug, I guess?
Comment 1•19 years ago
|
||
See bug 307560 comment 9. Depending on what gets decided there, we might not need changes here, possibly.
Depends on: 307560
Comment 2•19 years ago
|
||
So I'm suspecting that we don't need this change in general, unless there's potential for the newborn roots to be cleared... That doesn't seem to be the case for the three callsites here, as far as I can tell.
Updated•18 years ago
|
Assignee: dbradley → nobody
Updated•18 years ago
|
QA Contact: pschwartau → xpconnect
Comment 3•18 years ago
|
||
XPCNativeWrapper::GetNewOrUsed
(and GetScopeOfObject with stack containing
XPCNativeWrapper::GetNewOrUsed) is a trunk topcrasher.
Would fixing this help?
Comment 4•18 years ago
|
||
(In reply to comment #3)
> XPCNativeWrapper::GetNewOrUsed
> (and GetScopeOfObject with stack containing
> XPCNativeWrapper::GetNewOrUsed) is a trunk topcrasher.
> Would fixing this help?
See bug 370403.
/be
Updated•7 years ago
|
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•