Closed
Bug 18069
Opened 25 years ago
Closed 25 years ago
support per-object refcount tracing
Categories
(Core :: XPCOM, defect, P1)
Core
XPCOM
Tracking
()
RESOLVED
FIXED
M12
People
(Reporter: waterson, Assigned: waterson)
Details
(Keywords: memory-leak, Whiteboard: work is done. will check in once tree opens for M12)
Attachments
(1 file)
|
8.26 KB,
patch
|
Details | Diff | Splinter Review |
Add support for per-object refcount tracing.
|
Assignee | |
Updated•25 years ago
|
Status: NEW → ASSIGNED
Priority: P3 → P1
Whiteboard: work is done. will check in once tree opens for M12
Target Milestone: M12
|
|
Assignee | |
Comment 1•25 years ago
|
||
|
|
Assignee | |
Comment 2•25 years ago
|
||
warren, could you code review this for me? Here's what it does: When XPCOM_MEM_LOG_CLASSES is set, each object (whose type is included in the logged classes) will be assigned a unique serial number, starting at "1". At the end of the run, any -leaked- object will have its serial number printed in the bloat log; i.e., the file specified by XPCOM_MEM_BLOAT_LOG. Additionally setting XPCOM_MEM_LOG_OBJECTS to one (or more, comma separated) of these serial numbers, in conjunction with XPCOM_MEM_REFCNT_LOG, will cause a stack traces to be dumped for each addref/release. However, rather than dumping stack traces for -every- object, stack traces will only be dumped for objects whose serial numbers are listed in XPCOM_MEM_LOG_OBJECTS. Setting XPCOM_MEM_LOG_CLASSES and XPCOM_MEM_REFCNT_LOG -without- setting XPCOM_MEM_LOG_OBJECTS still works like it did before: that is, every object has its addrefs/releases logged.
|
|
Assignee | |
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
|
|
Assignee | |
Comment 3•25 years ago
|
||
checked in, r=warren
Component: XP Miscellany → XPCOM
Keywords: mlk
Summary: [mlk] support per-object refcount tracing → support per-object refcount tracing
You need to log in
before you can comment on or make changes to this bug.
Description
•