1279903 - Full-page reloads while debugging leaks plenty of memory - detatched window objects hanging around

Status: RESOLVED FIXED

(DevTools :: Debugger, defect, P2)

Description

[Hallvord R. M. Steen [:hallvors]]

Attachment: g-contacts-after-reloads-memory-report.json.gz

The debugger's performance tends to deteriorate over time, more during some debug sessions than others. I think it's a memory management issue.

Today I've done some experiments monitoring about:memory, and it seems that doing full-page reloads while the debugger is stopped at a breakpoint causes poor performance while the about:memory page shows plenty of "detatched" window objects. I don't have a lot of experience in this area but I hope this is the cause of the slowdowns. I'll attach a saved memory analysis.

FWIW, the complexish web app I was testing against was
https://contacts.google.com/u/0/preview/all
(randomly because I'm trying to understand bug 1267526)

Steps to reproduce:
1) Open URL and devtools in latest nightly
2) In debugger, tell it to break on input events
3) Choose to edit a contact, type a random letter in a field
4) Do 4-5 "Step into" actions
5) Reload the contacts.google.com page
6) Repeat steps 3-5 once or twice, measure memory each time

Comment 1

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

The sounds similar to issues :fitzgen was investigating in bug 1261869.

Comment 2

[Eddy Bruel [:ejpbruel]]

This isn't an immediate showstopper, but it's definitely one of those things that prevents our debugger from being awesome. That said, I'm reluctant to mark this as P1 because this looks like a frontend issue. We're currently putting a lot of effort into completely rewriting the frontend, so unless this prevents people from getting work done, it feels inefficient to spend a lot of time fixing memory leaks in a frontend that we know will be deprecated in the near future.

Nick, if you feel like it, could you spend some time looking into this? If it's something that's easily fixed, it might be worth doing so. If it turns out to be a very hard problem, then perhaps we should leave it be for now.

Comment 3

[Kumar Harsh]

(In reply to Eddy Bruel [:ejpbruel] from comment #2)
> unless this prevents people from getting work done

This has become a huge issue over time - even with Quantum.

When I set a breakpoint in a react component, and then reload the page, Firefox starts reloading the page after about 10 second, but the reload **never** finishes - all XHR queries time out after some time, but the page never loads. I have to close the debugger and then reload the page again - effectively stopping me from debugging any error which happens when a page loads. I think that the issue is a big showstopper from developers even trying to use the rest of the dev-tools.

Comment 4

[:Harald Kirschner :digitarald]

I tried the example page above and its working fine in Nightly (not using pause on events, as that is only re-landing in coming releases). Closing for now, but we should keep trying against large web apps.

Kumar, do you have a test case for this?

Comment 5

[Kumar Harsh]

(In reply to :Harald Kirschner :digitarald from comment #4)
> I tried the example page above and its working fine in Nightly (not using
> pause on events, as that is only re-landing in coming releases). Closing for
> now, but we should keep trying against large web apps.
> 
> Kumar, do you have a test case for this?

It seems to have solved itself as of Firefox 64 release.