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

NEW
Unassigned

Status

()

defect
P3
normal
6 years ago
2 years ago

People

(Reporter: florian, Unassigned)

Tracking

(Blocks 1 bug)

Trunk
x86
macOS
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(3 attachments)

(Reporter)

Description

6 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 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.
(Reporter)

Comment 1

6 years ago
Posted file gzipped DMD output
(Reporter)

Comment 2

6 years ago
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: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
You need to log in before you can comment on or make changes to this bug.