Closed Bug 963878 Opened 6 years ago Closed 2 years ago

Leak with large text node containing LRO

Categories

(Core :: Layout: Text and Fonts, defect, P3)

x86_64
macOS
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jruderman, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: memory-leak, regression, testcase)

Attachments

(1 file)

Attached file testcase
1. Run Firefox with XPCOM_MEM_LEAK_LOG=2
2. Load the testcase
3. Quit Firefox

Result: trace-refcnt reports that Firefox leaked an "nsTArray_base" object.

This is a regression from bug 955957.
Flags: needinfo?(jfkthame)
Priority: -- → P3
I don't think bug 955957 has actually introduced a new leak, as it didn't change anything about the ownership or lifetime of gfxSkipChars; however, the old implementation was not tracked by the leak-checking code, so we didn't notice. Now that it has an nsTArray member, suddenly it becomes visible.

I believe the object being leaked here is the static const variable emptySkipChars from http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsTextFrame.cpp#2617. As a static, it gets created (including its nsTArray member) the first time we hit this particular codepath (if at all), and then never gets deleted.

It appears that BuildTextRun() is failing to construct the necessary textrun for a frame in this example, but I haven't tracked down why that's happening or whether it will result in other problems (though the "this is bad" comment at http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsTextFrame.cpp#2615 is worrying). The apparent leak is simply a side-effect of this failure.
Flags: needinfo?(jfkthame)
No longer reproduces on trunk.
Status: NEW → RESOLVED
Closed: 2 years ago
Flags: in-testsuite+
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.