When I run the test_textbox_number.xul test, I leak 52 nsAutoRepeatBoxFrame objects, and at 112 bytes each that comes to 5824 bytes total. This is the vast majority of refcount leaks when I run Mochitests on Windows with refcount leak logging.
After some investigation, it seems that the frames are being destroyed properly. However, the AutoRepeatBoxFrame implements nsITimerCallback, yet frames don't handle refcounting. Maybe something wrong with the way the logging is being reported.
The logging happens in NS_IMPL_ADDREF_INHERITED and NS_IMPL_RELEASE_INHERITED. The logging really wants to be in the constructor/destructor with MOZ_COUNT_(C|D)TOR as frames aren't really XPCOM, but unless you inline the macros you can't really do that. Leaking references to the frames, however, seems more than a little scary if you can get those references to be dropped after the frame is unilaterally destroyed. You can get the stacks for the addrefs/releases using XPCOM_MEM_REFCNT_LOG=filename, XPCOM_MEM_LOG_CLASSES=nsAutoRepeatBoxFrame, and XPCOM_MEM_LOG_OBJECTS=the serial numbers of the "leaked" frames, as determined by running with just LOG_CLASSES and REFCNT_LOG set, which will probably help with figuring this out. The following URL expands on this in more detail: http://www.mozilla.org/performance/refcnt-balancer.html
Flags: blocking1.9? → blocking1.9-
Bug 322940 suggests the right solution may be to not use the NS_IMPL macros.
Frames shouldn't implement nsITimerCallback.
This got fixed by bug 415684 (which removed nsITimerCallback from nsAutoRepeatBoxFrame).
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 415684
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: xptoolkit.xul → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.