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




5 years ago
8 months ago


(Reporter: florian, Unassigned)


(Blocks: 1 bug)

Mac OS X

Firefox Tracking Flags

(Not tracked)


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


(3 attachments)



5 years ago
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.

Comment 1

5 years ago
Created attachment 731678 [details]
gzipped DMD output

Comment 2

5 years ago
Created attachment 731679 [details]
Created attachment 731683 [details]
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.
Blocks: 563700
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]
You need to log in before you can comment on or make changes to this bug.