Open Bug 842309 Opened 13 years ago Updated 3 years ago

Leak with @import, mask url

Categories

(Core :: CSS Parsing and Computation, defect)

x86_64
macOS
defect

Tracking

()

People

(Reporter: jruderman, Unassigned)

References

Details

(Keywords: memory-leak, testcase)

Attachments

(2 files)

Attached file testcase
With XPCOM_MEM_LEAK_LOG=2, trace-refcnt reports that several objects leak. The contents of the imported sheet: * { mask: url(#m); }
Attached file what leaked?
Hmm. Why are we leaking HTML parser stuff here?
| 1 nsBaseChannel::OnStartRequest(nsIRequest*, nsISupports*) (nsBaseChannel.cpp:720, in XUL) | 1 non-virtual thunk to nsExternalResourceMap::PendingLoad::OnStartRequest(nsIRequest*, nsISupports*) (in XUL) + 55 | 2 nsExternalResourceMap::PendingLoad::OnStartRequest(nsIRequest*, nsISupports*) (nsDocument.cpp:944, in XUL) | | 2 nsExternalResourceMap::PendingLoad::SetupViewer(nsIRequest*, nsIContentViewer**, nsILoadGroup**) (nsDocument.cpp:1018, in XUL)
So we're setting up a parser and whatnot, then checking whether we got an XML parser. If we didn't (as here), we cancel the load by returning an error from OnStartRequest. Henri, should we be doing something to clean up the parser here too? I guess the parser never gets an OnStartRequest + failure code in this case; should it do that or something?
Flags: needinfo?(hsivonen)
So the HTML parser stuff that leaks is the stuff whose life time is tied to what happens on the parser thread. (In reply to Boris Zbarsky (:bz) from comment #4) > So we're setting up a parser and whatnot, then checking whether we got an > XML parser. If we didn't (as here), we cancel the load by returning an > error from OnStartRequest. > > Henri, should we be doing something to clean up the parser here too? I > guess the parser never gets an OnStartRequest + failure code in this case; > should it do that or something? My best current guess from looking at the code (not actually debugging) is that nsHtml5Parser::~nsHtml5Parser() should call DropStreamParser(). Currently the stream parser gets explicitly dropped only when a parse that was started ends or when the CC unlinks nsHtml5Parser.
Flags: needinfo?(hsivonen)
I tried that, but it doesn't help. In particular, I'm seeing mStreamParser always be null in the destructor there. Henri, do you have the bandwidth to look into this or should I?
Flags: needinfo?(hsivonen)
My bandwidth is rather bad at the moment, sorry.
Flags: needinfo?(hsivonen)
This still leaks the same objects.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: