399235 - Leaking 52 nsAutoRepeatBoxFrames running test_textbox_number.xul

Status: RESOLVED DUPLICATE of bug 415684

(Core :: XUL, defect)

Description

[Jeff Walden [:Waldo]]

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.

Comment 1

[Neil Deakin]

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.

Comment 2

[Jeff Walden [:Waldo]]

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

Comment 3

[Jeff Walden [:Waldo]]

Bug 322940 suggests the right solution may be to not use the NS_IMPL macros.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Frames shouldn't implement nsITimerCallback.

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This got fixed by bug 415684 (which removed nsITimerCallback from nsAutoRepeatBoxFrame).