Open
Bug 842309
Opened 13 years ago
Updated 3 years ago
Leak with @import, mask url
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
NEW
People
(Reporter: jruderman, Unassigned)
References
Details
(Keywords: memory-leak, testcase)
Attachments
(2 files)
With XPCOM_MEM_LEAK_LOG=2, trace-refcnt reports that several objects leak.
The contents of the imported sheet:
* { mask: url(#m); }
Reporter | ||
Comment 1•13 years ago
|
||
![]() |
||
Comment 2•13 years ago
|
||
Hmm. Why are we leaking HTML parser stuff here?
![]() |
||
Comment 3•13 years ago
|
||
| 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)
![]() |
||
Comment 4•13 years ago
|
||
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?
![]() |
||
Updated•13 years ago
|
Flags: needinfo?(hsivonen)
Comment 5•13 years ago
|
||
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)
![]() |
||
Comment 6•13 years ago
|
||
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)
Comment 8•10 years ago
|
||
This still leaks the same objects.
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•