Open
Bug 856443
Opened 11 years ago
Updated 3 years ago
Large heap-unclassified caused by XHR when keeping a page open
Categories
(Core :: Networking, defect, P5)
Tracking
()
NEW
People
(Reporter: florian, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [MemShrink:P3][necko-backlog])
Attachments
(3 files)
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•11 years ago
|
||
Reporter | ||
Comment 2•11 years ago
|
||
Comment 3•11 years ago
|
||
At first glance, it mostly looks like networking-y stuff, plus some stuff allocated by the bindings themselves.
Updated•11 years ago
|
Blocks: DarkMatter
Comment 4•11 years ago
|
||
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•11 years ago
|
||
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•11 years ago
|
||
Yeah, I don't recognize those allocation stacks. bz, do you know where those blocks end up being stored?
![]() |
||
Comment 7•11 years ago
|
||
The ones I saw, mostly in various data structures hanging off of HTTP channels.
Updated•8 years ago
|
Whiteboard: [MemShrink:P3] → [MemShrink:P3][necko-backlog]
Comment 9•6 years ago
|
||
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Comment 10•6 years ago
|
||
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
Comment 11•3 years ago
|
||
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
You need to log in
before you can comment on or make changes to this bug.
Description
•