728632 - Leak with CSS mask pointing to HTML document

Status: NEW

(Core :: DOM: HTML Parser, defect)

Description

[Jesse Ruderman]

Attachment: testcase

1. Run a debug build of Firefox with XPCOM_MEM_LEAK_LOG=2
2. Load the testcase
3. Quit Firefox

Result: trace-refcnt reports leak of nsHtml5StreamParser, nsHtml5Tokenizer, nsHtml5TreeBuilder, nsTimerImpl, and more.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Hmm.  So in this case, we would get to nsExternalResourceMap::PendingLoad::SetupViewer, create the content viewer and the parser, then error out because it's not an XML parser.  We never end up calling into the parser we set up.

It looks like the HTML parser is setting up some reference cycles here or something, and nothing is breaking them?  Henri, what does the parser rely on to break these cycles?

Note that if I wait for a bit the whole leak thing thing goes away.  So something is actually holding a _temporary_ ref to the parser and not dropping it at shutdown.

Comment 2

[Boris Zbarsky [:bzbarsky]]

I bet the mFlushTimer is what's keeping things alive here.

Comment 3

[Henri Sivonen (:hsivonen)]

(In reply to Boris Zbarsky (:bz) from comment #1)
> It looks like the HTML parser is setting up some reference cycles here or
> something, and nothing is breaking them?  Henri, what does the parser rely
> on to break these cycles?

IIRC, any one of:
 1) Stream ends
 2) nsIParser::Terminate() gets called
 3) The cycle collector does what it does
causes a call to nsHtml5StreamParser::DropTimer().

Note that in all these scenarios, actually releasing all parts of the parser take the round trip of posting a runnable to the parser thread from the main thread, having it run there and posting a runnable from the parser thread to the main thread and having it run there.

It's quite possible that the parser thread gets shut down too soon for this to happen at shutdown. However, I don't expect this to be a "real" leak in the sense of leaking before shutdown, so we should be OK when we start quitting by exit().

Comment 4

[Andrew McCreight [:mccr8]]

Still happens.

Comment 5

[Jesse Ruderman]

Attachment: testcase 2

Comment 6

[Ryan VanderMeulen [:RyanVM]]

Confirmed on Try that this still happens intermittently (~30% of the time on OSX).

https://treeherder.mozilla.org/logviewer.html#?job_id=149841784&repo=try
TEST-INFO | leakcheck | tab process: leaked 1 CondVar
TEST-INFO | leakcheck | tab process: leaked 11 Mutex
TEST-INFO | leakcheck | tab process: leaked 4 Runnable
TEST-INFO | leakcheck | tab process: leaked 1 ThreadEventTarget
TEST-INFO | leakcheck | tab process: leaked 1 ThreadTargetSink
TEST-INFO | leakcheck | tab process: leaked 2 nsHtml5AttributeName
TEST-INFO | leakcheck | tab process: leaked 2 nsHtml5ElementName
TEST-INFO | leakcheck | tab process: leaked 2 nsHtml5StreamParser
TEST-INFO | leakcheck | tab process: leaked 2 nsHtml5Tokenizer
TEST-INFO | leakcheck | tab process: leaked 2 nsHtml5TreeBuilder
TEST-INFO | leakcheck | tab process: leaked 12 nsTArray_base
TEST-INFO | leakcheck | tab process: leaked 1 nsThread
TEST-INFO | leakcheck | tab process: leaked 2 nsTimer
TEST-INFO | leakcheck | tab process: leaked 2 nsTimerImpl
TEST-UNEXPECTED-FAIL | leakcheck | tab process: 5360 bytes leaked (CondVar, Mutex, Runnable, ThreadEventTarget, ThreadTargetSink, ...)