HoldJSObjects/DropJSObjects audit

NEW
Unassigned

Status

()

Core
XPCOM
4 years ago
a year ago

People

(Reporter: mccr8, Unassigned)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
HoldJSObjects should only be called in the constructor, DropJSObjects should only be called in the destructor.  Failure to do that can interact with other weirdness to lead to use-after-free problems.

Comment 1

4 years ago
I think calling HoldJSObjects only in ctor is too strict. It makes us to put more than needed objects to jsholders.
(Reporter)

Comment 2

4 years ago
Yeah, I suppose that's true.  I could do some profiling of what % of each object class ends up holding JS alive, though I guess it will be hard to come up with test cases for that.

Comment 3

4 years ago
Most of the DOM Nodes don't preserve wrapper, so they don't hold js objects by default.
(Reporter)

Comment 4

4 years ago
I wasn't planning on messing with nodes, just the random misc. junk we have floating around.

Comment 5

4 years ago
Ah, in that case calling HoldJSObjects always might work.

Comment 6

a year ago
Was there anything left to do here Andrew, or was this meta-bug just waiting on its dependencies to be fixed?
Flags: needinfo?(continuation)
(Reporter)

Comment 7

a year ago
(In reply to Thomas Wisniewski from comment #6)
> Was there anything left to do here Andrew, or was this meta-bug just waiting
> on its dependencies to be fixed?

There's probably more to do. I got distracted in the middle of my audit so there's probably more to fix.
Flags: needinfo?(continuation)
(Reporter)

Updated

a year ago
Assignee: continuation → nobody
You need to log in before you can comment on or make changes to this bug.