Open
Bug 1255478
Opened 8 years ago
Updated 2 years ago
Add a way to ignore leaks of individual objects in the XPCOM leak detector
Categories
(Core :: XPCOM, defect)
Core
XPCOM
Tracking
()
NEW
Tracking | Status | |
---|---|---|
firefox48 | --- | affected |
People
(Reporter: mccr8, Unassigned)
References
(Blocks 1 open bug)
Details
In bug 1242084, there is telemetry-related code that runs very late in shutdown and uses XPCOM strings, so when telemetry is enabled in debug builds (which it is not currently), then we end up with an 8 byte leak of a string buffer. One approach to silencing this leak would be to add a facility to ignore the leak of an individual object in the XPCOM leak checker. This is opening a bit of a Pandora's box, but we already have an equivalent facility in MOZ_LSAN_INTENTIONALLY_LEAK_OBJECT (which was introduced for this same code), and it hasn't been abused yet. It would be nice if this was somewhat robust, so if for instance you passed the same object in twice it would not double count it.
Reporter | ||
Comment 1•8 years ago
|
||
There's already a way to ignore a specific number of leaked objects at the test harness layer, but objects leaked that way still show up in the bloat log, which can be confusing for developers (I've seen at least one instance of this happening for our content process leaks). We could also avoid this confusion by not echoing out the bloat log, and changing the output somehow so it is more clear what is a known leak.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•