Open Bug 856443 Opened 12 years ago Updated 5 months ago

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


(Core :: Networking, defect, P5)





(Reporter: florian, Unassigned)


(Blocks 1 open bug)


(Whiteboard: [MemShrink:P3][necko-backlog])


(3 files, 1 obsolete file)

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 22.0a1) with DMD enabled.

The page is a bandwidth chart at /Status_Bandwidth.asp on a wifi router running a firmware from (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.
Attached file gzipped DMD output
Attached file about:memory?verbose
At first glance, it mostly looks like networking-y stuff, plus some stuff allocated by the bindings themselves.
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.
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.
Yeah, I don't recognize those allocation stacks.  bz, do you know where those blocks end up being stored?
The ones I saw, mostly in various data structures hanging off of HTTP channels.
Sounds like the page is at fault.
Whiteboard: [MemShrink] → [MemShrink:P3]
Whiteboard: [MemShrink:P3] → [MemShrink:P3][necko-backlog]
Bulk change to priority:
Priority: -- → P1
Bulk change to priority:
Priority: P1 → P3

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.

Severity: normal → S4
Priority: P3 → P5
Attachment #9384448 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.