Closed Bug 1122249 Opened 9 years ago Closed 8 years ago

Intermittent leakcheck | default process: 9750951 bytes leaked (AnimationTimeline, AsyncLatencyLogger, AsyncStatement, AtomImpl, Attr, ...)

Categories

(DevTools Graveyard :: Scratchpad, defect)

Product:
DevTools Graveyard
Component:
Scratchpad
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(firefox36 unaffected, firefox37 unaffected, firefox38 affected, firefox39 disabled, firefox-esr31 unaffected)

Status:
RESOLVED DUPLICATE of bug 1186675
Tracking Flags:
Tracking Status
firefox36 --- unaffected
firefox37 --- unaffected
firefox38 --- affected
firefox39 --- disabled
firefox-esr31 --- unaffected

People

(Reporter: RyanVM, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: intermittent-failure, memory-leak)

Blocks: 933741
(In reply to Ryan VanderMeulen [:RyanVM UTC-5] from comment #0)
> See the "Leaked URLs" section.

What about it?  Just that it has a kajillion entries?
This leak includes 25 nsGlobalWindows and 103 nsDocuments, which is a lot.
As in "there's no way I'm copying & pasting that entire monster here"
Ah, ok.  The list is so giant isn't going to be of value anyways.
Component: General → Developer Tools: Scratchpad
Product: Core → Firefox
Version: 36 Branch → Trunk
This leak is alarmingly frequent and large.  Fortunately, since browser-chrome is run-by-directory we can narrow it down a bit.  The last two occurences of this (comment 12 is misstarred...) are in the scratchpad directory.  Has something related landed recently?
[Tracking Requested - why for this release]: very large, fairly frequent intermittent leak, though it seems like it is restricted to one test directory on OSX 10.8, which is weird.
The patches in bug 1127201 have been backed out, and I worked out which part was responsible (though I still don't know why) and I will reland some tweaked patches that should avoid this problem. So I'll mark this as resolved.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Assignee: nobody → n.nethercote
status-firefox36: --- → unaffected
status-firefox37: --- → unaffected
status-firefox38: --- → fixed
status-firefox-esr31: --- → unaffected
Target Milestone: --- → Firefox 38
This started happening again.  It is in the scratchpad directory again, OSX 10.8 only.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee: n.nethercote → nobody
Ryan, do you have time to bisect this with retriggers or should I?
Flags: needinfo?(ryanvm)
I'll give it a shot.
Flags: needinfo?(ryanvm)
Regression from bug 1138616.
http://www.quickmeme.com/img/5b/5b7e0fdd39178dc8d4148618607fc96fb8908a1ea62c04119630f50f349c4ce1.jpg
Blocks: 1138616
status-firefox39: --- → affected
Flags: needinfo?(continuation)
Target Milestone: Firefox 38 → ---
That's peculiar.  Thanks for finding the regression.
Flags: needinfo?(continuation)
The leaking pair of inner/outer windows is the second pair created during the test run, before any tests are actually begun.  That doesn't seem very useful.
Is it possible this was showing up in some other form before the regression?
This smells to me like it's some kind of latent defect that is randomly getting triggered by unlucky patches, and it then holds them hostage :(
Yeah I think so.  Maybe some timing issue?  I'm not sure what could trigger leaks this severe.  It almost seems like a CC OOM, but there's no evidence of that in the log, and it is only leaking 2 windows, just a bunch of documents.
I might just start disabling tests in this directory on 10.8 to try to figure out which one is causing problems.  Or maybe do some try pushes, though that seems a little wasteful.
This seems to reproduce 100% of the time on my local OSX 10.10 machine.  I can remove tests until there are only 7 running, and it reproduces, but not any further.  It doesn't seem to matter a huge amount which 7 are involved.

The leaks happen though an nsXPCWrappedJS (nsINavHistoryObserver).  The only C++ that I see that holds alive things of that type on the heap is nsNavHistory, which is some singleton.  I'm not sure why it isn't being destroyed in this case.
Unsurprisingly, this is now happening on Aurora thanks to the landing of the bug that caused it there...
We seem not to run 10.8 tests on trunk any more.
status-firefox38: fixed → affected
status-firefox39: affected → disabled
Last seen in July 2015. However, I bet what happened here was that the Attr class was renamed which caused this to change. So this really just morphed into bug 1186675.
Status: REOPENED → RESOLVED
Closed: 9 years ago → 8 years ago
Resolution: --- → DUPLICATE
Product: Firefox → DevTools
Product: DevTools → DevTools Graveyard
You need to log in before you can comment on or make changes to this bug.