Add a more explicit assertion in NS_CycleCollectorSuspect3()
Categories
(Core :: XPCOM, task)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox104 | --- | fixed |
People
(Reporter: mccr8, Assigned: mccr8)
References
Details
Attachments
(1 file)
NS_CycleCollectorSuspect3 will crash, either with an assert or a null deref, if there is no active cycle collector on the current thread. We should change this into an assert and spell out more explicitly what might be going wrong.
A number of other methods use the result of sCollectorData.get(), but they rest of them look more like internal CC kinds of APIs, whereas NS_CycleCollectorSuspect3 can get invoked any time a cycle collected object is addrefed or released, so developers who aren't experts on the CC are more likely to run afoul of it. (I filed this bug in response to an instance of developer confusion.)
| Assignee | ||
Comment 1•3 years ago
|
||
While sCollectorData.get() can be null in a number of places, this
method is where developers are most likely to hit it, because it
can be caused by using a cycle collected object on a thread
without a cycle collector. This adds a more descriptive assertion
message, and a comment with even more detail. I also made it
into a release assert so the crash will hopefully be more
understandable in release builds, too.
Comment 3•3 years ago
|
||
| bugherder | ||
Description
•