856443 - Large heap-unclassified caused by XHR when keeping a page open

Status: NEW

(Core :: Networking, defect, P5)

Description

[Florian Quèze [:florian]]

I observed some large heap-unclassified (1+GB) in my default Firefox (19.0.2) profile and noticed that it went away when closing a specific page, so I've loaded that page in a build (from http://hg.mozilla.org/mozilla-central/rev/8693d1d4c86d 22.0a1) with DMD enabled.

The page is a bandwidth chart at /Status_Bandwidth.asp on a wifi router running a firmware from dd-wrt.com (version DD-WRT v24-sp2 (10/10/09) mini).
The chart seems to be drawn using SVG, so I first assumed it was SVG that was consuming all that memory. DMD proved my guess wrong though, it's XHR that's using a lot of memory. When I was connected to the router, the memory usage was small (heap-unclassified was around 20MB); it started climbing only after waking up my laptop on a different wifi network (after a night, heap-unclassified was > 1GB), so it seems to be only failed XHRs that are kept in memory until the page is closed.

I don't know how the JS code using XHR looks, so I don't know if keeping these XHRs around is the page's fault or not. There's a bug here either way; I'm just not sure if the bug is having that memory in heap-unclassified instead of blaming it to the page, or if the bug is a leak. I hope someone who knows the code will be able to find out from the attached DMD output.

Comment 1

[Florian Quèze [:florian]]

Attachment: gzipped DMD output

Comment 2

[Florian Quèze [:florian]]

Attachment: about:memory?verbose

Comment 3

[Andrew McCreight [:mccr8]]

Attachment: first 1000 lines of the DMD logs, covering the bulk of allocations

At first glance, it mostly looks like networking-y stuff, plus some stuff allocated by the bindings themselves.

Comment 4

[Andrew McCreight [:mccr8]]

One possibility, just guessing here, is that XHRs are being kept alive purely by JS.  The current orphan reporter only looks at nodes, so maybe in that case they are going to be missed?  I'm not sure what exactly tracks XHR usage right now.

Comment 5

[Boris Zbarsky [:bzbarsky]]

We track XHR usage via event target bits, but it looks like the memory in this case is things like the request/response headers for the various channels, etc, which we almost certainly have no reporters for.

Comment 6

[Nicholas Nethercote [inactive]]

Yeah, I don't recognize those allocation stacks.  bz, do you know where those blocks end up being stored?

Comment 7

[Boris Zbarsky [:bzbarsky]]

The ones I saw, mostly in various data structures hanging off of HTTP channels.

Comment 8

[Nicholas Nethercote [inactive]]

Sounds like the page is at fault.

Comment 9

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 10

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 11

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.

Comment 12

[Norma Sparks]

Attachment: same problem

Thanks from plancitercpip1973.