Open
Bug 841930
Opened 13 years ago
Updated 3 years ago
dom/media/tests/crashtest/801227.html "Leaking the World."
Categories
(Core :: WebRTC: Audio/Video, defect, P5)
Core
WebRTC: Audio/Video
Tracking
()
NEW
| backlog | webrtc/webaudio+ |
People
(Reporter: jesup, Unassigned)
References
Details
(Keywords: memory-leak, Whiteboard: [MemShrink:P3])
Attachments
(3 files)
801227.html leaks a ton of stuff, but none of it having to do with WebRTC.
|
||
Comment 1•13 years ago
|
||
Randell and Jan-Ivar -- I assume you'll work this together since we want to understand what's going on here as soon as we can.
Assignee: nobody → jib
Priority: P2 → P1
|
||
Comment 2•13 years ago
|
||
Brain dump: The marker I use for this leak is the line "Leaking the RDF Service" in the output (and you can see it in the original attachment of this bug). It leaks the same ton of objects each time, including two nsXULDocument's and nsHTMLDocument's (please tell me if there are bigger objects I should track). I can reproduce this in a regular browser session as well, so it's real.
I should note that I've triggered this leak (or a leak exactly like it), several times WITHOUT EVEN CALLING ANY GUM OR WEBRTC CODE (!), alas not reliably. Just when I thought I had it cornered without using any of our code, it stopped happening (so I wont rule out pilot error). But note that no gum or webrtc objects show up in the leak or even the balance tree AFAICT, so there's a chance this is just bad timing and not our fault.
That said, my only reliable reproduce steps are with mosGetUserMedia and are solid, so that concerns me. I loaded a slightly modified crashtest into the browser for my tests:
<!DOCTYPE HTML>
<html class="reftest-wait">
<!-- https://bugzilla.mozilla.org/show_bug.cgi?id=801227 -->
<head>
<meta charset="utf-8">
<title>Abort due to page reload</title>
<script type="application/javascript">
function finish() {}
function start() {
var index = parseInt(localStorage.index) || 0;
if (index < 1) {
localStorage.index = index + 1;
window.location.reload();
navigator.mozGetUserMedia({ audio: false, fake: true }, finish, finish);
} else {
delete localStorage["index"];
document.documentElement.removeAttribute("class");
}
}
</script>
</head>
<body onload="setTimeout(start, 100)">Hi</body></html>
My first attempt was a dead-end, I tried manually tracing back from the "Leaking the RDF Service", which is part of nsLayoutStatistics. I found that the 36th nsNodeInfoManager leaks, and the stack-trace led back to an nsXULDocument. Didn't learn much.
So I then stepped back and did a balance tree of nsHTMLDocument instead, which is this attachment. Seems more promising, except it's big and I could really use some help deciphering it.
Thoughts welcome.
|
||
Comment 3•13 years ago
|
||
Adding some MemShrink guys on to the bug to see if they have any insight into this large memory leak.
Whiteboard: [webrtc][blocking-webrtc+] → [webrtc][blocking-webrtc+][MemShrink]
Keywords: mlk
|
|
||
Comment 4•13 years ago
|
||
I guess the question if this is a test-only thing or if it's manifesting in real-world situations...
Whiteboard: [webrtc][blocking-webrtc+][MemShrink] → [webrtc][blocking-webrtc+][MemShrink:P2]
|
|
||
Comment 5•13 years ago
|
||
I've observed the leak outside our testing-harness in a regular (debug) browser session, but so far, the leaks don't seem to accumulate, so any real-world effects would limited to the 3 Mb.
|
|
||
Updated•12 years ago
|
Whiteboard: [webrtc][blocking-webrtc+][MemShrink:P2] → [webrtc][blocking-webrtc-][MemShrink:P2]
|
|
||
Updated•12 years ago
|
Summary: dom/media/tests/crashtest/801227.html leaks the world → dom/media/tests/crashtest/801227.html "Leaking the RDF Service."
|
|
||
Comment 6•12 years ago
|
||
RDF service is leaking? Hmm...let's bounce this over to the RDF component to see if anyone over there knows what's going on here.
Component: WebRTC: Audio/Video → RDF
QA Contact: jsmith
|
||
Comment 7•12 years ago
|
||
Bouncing back to WebRTC, RDF is only me, and I know jack about memory management.
CCing peterv, though, I recall him involving RDF in cycle collection. No idea if that's remotely related, though. Also Trevor, he's doing memory landings in RDF.
I don't think it's either's fault, but they might have a clue what to look for.
Component: RDF → WebRTC: Audio/Video
QA Contact: jsmith
|
|
||
Comment 8•12 years ago
|
||
Sounds right, as the printf in question is after-the-fact. Whole Documents are leaking, so a lot of modules could printf that their stuff leaked. Doesn't mean they're to blame.
Still, that text is an effective identifier of the leak now, which is why I put it in the subject so others who experience it can find it searching bugzilla.
|
||
Comment 9•12 years ago
|
||
(In reply to Jan-Ivar Bruaroey [:jib] from comment #8)
> Sounds right, as the printf in question is after-the-fact. Whole Documents
> are leaking, so a lot of modules could printf that their stuff leaked.
> Doesn't mean they're to blame.
I would tend to agree that the document leak is the real problem here, istr xul documents have a global ref to the rdf service they share, so I believe if you leak a xul doc you leak the rdf service.
|
|
||
Updated•10 years ago
|
backlog: --- → webRTC+
Rank: 15
Whiteboard: [webrtc][blocking-webrtc-][MemShrink:P2] → [MemShrink]
|
|
||
Comment 11•10 years ago
|
||
Yes, still happens for me on OSX. Here's a fresh run.
STR:
1. Change dom/media/tests/crashtests/crashtests.list to just load 801227.html
2. ./mach crashtest dom/media/tests/crashtests
Note that 801227.html and 822197.html were removed for perma-oranges in 2013 and never re-enabled [1], but the files still exist in the tree.
[1] http://hg.mozilla.org/mozilla-central/rev/31fa1546a849
Flags: needinfo?(jib)
|
|
||
Updated•10 years ago
|
Summary: dom/media/tests/crashtest/801227.html "Leaking the RDF Service." → dom/media/tests/crashtest/801227.html "Leaking the World."
|
|
||
Comment 12•10 years ago
|
||
Old ranking. Not working on it right now. Requesting reassigning.
Assignee: jib → nobody
Flags: needinfo?(mreavy)
Priority: P1 → --
|
|
||
Comment 13•10 years ago
|
||
May move this to backlog once we determine if this has any real world impacts.
Rank: 15 → 45
Flags: needinfo?(mreavy)
Priority: -- → P4
|
||
Updated•10 years ago
|
Whiteboard: [MemShrink] → [MemShrink:P3]
|
||
Comment 14•8 years ago
|
||
Mass change P4->P5 to align with new Mozilla triage process.
Priority: P4 → P5
|
||
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•