Memory keeps going up and up in self-refreshing pages at flickr
Categories
(Core :: Graphics: ImageLib, defect, P3)
Tracking
()
People
(Reporter: jamesrome, Unassigned)
Details
(Keywords: memory-leak, Whiteboard: [MemShrink:P2])
Attachments
(2 files)
My firefox on OS X 10.8.4 keeps using more and more and more memory, even though I set browser.sessionhistory.max_total_viewers to 0. My Mac Pro has 2 12-core Xenons and 32 GB of memory, of which there is a lot free. However, OS X starts swapping memory when Firefox goes above 1.5 GB or so, making it slower and slower and slower. When it gets to > 2.5 GB, I have to kill Firefox and restart. This is especially apparent if you go to flickr and start clicking the right arrow to page through pictures. Firefox does not clear itself of the old images, and the memory use steadily increases with each picture. For example start with http://www.flickr.com/photos/tjtj/9107786769/in/set-72157634263491285 and click the right arrow. I am barely able to even type this report with 2.2GB being used by Firefox. Using other browsers does not give me this grief (Safari, Chrome, Opera Next)
Reporter | ||
Comment 1•11 years ago
|
||
In Firefox 24 on 10.8.5, I had just 2 pages open: http://online.wsj.com/home-page?refresh=on http://www.wunderground.com/radar/mixedcomposite.asp?region=c4&size=2x&type=loop&MR=1 It started using about 500MB of memory. I minimized it and came back a day later. It is now up to 3277MB of memory and is totally unusable. I can no longer use Firefox, my favorite browser. This is a critical bug. You have to be able to handle self-refreshing pages properly.
Reporter | ||
Updated•11 years ago
|
Updated•11 years ago
|
Reporter | ||
Comment 2•10 years ago
|
||
This is still a problem in FF31. I can no longer use Firefox :-(. It again becomes totally unresponsive, and a check shows that it has 2.1 GB of memory in use, and is being swapped like mad. I would have thought that this would be fixed by now. I use the same pages in Opera, and it has no memory issues.
Reporter | ||
Comment 3•10 years ago
|
||
Now on OS X 10.9
Comment 4•10 years ago
|
||
(In reply to James Rome from comment #1) > In Firefox 24 on 10.8.5, I had just 2 pages open: > http://online.wsj.com/home-page?refresh=on > http://www.wunderground.com/radar/mixedcomposite. > asp?region=c4&size=2x&type=loop&MR=1 bug 523950(In reply to James Rome from comment #0) > My firefox on OS X 10.8.4 keeps using more and more and more memory, even > though I set browser.sessionhistory.max_total_viewers to 0. My Mac Pro has 2 I don't think this setting is intended to impact images. > This is especially apparent if you go to flickr and start clicking the right > arrow to page through pictures. Firefox does not clear itself of the old > images, and the memory use steadily increases with each picture. For example > start with > http://www.flickr.com/photos/tjtj/9107786769/in/set-72157634263491285 and > click the right arrow. this isn't self refreshing. perhaps a dup of one of the bugs blocking bug 683284? https://bugzilla.mozilla.org/buglist.cgi?bug_id=683286%2C664291%2C854783%2C386451%2C739245%2C523950%2C700545%2C854784%2C511899%2C941606%2C682638%2C686905%2C715919%2C699150%2C691169&list_id=10600864
Reporter | ||
Comment 5•10 years ago
|
||
Could also be from http://www.wunderground.com/radar/radblast.asp?ID=MRX&lat=35.96273804&lon=-84.29615784&label=Oak+Ridge%2C+TN&type=N0R&zoommode=pan&map.x=400&map.y=240¢erx=400¢ery=240&prevzoom=zoom&num=10&delay=100&scale=1&showlabels=1&smooth=0&noclutter=1&showstorms=10&rainsnow=Show&lightning=Show or http://online.wsj.com/home-page?zone=intromessage?refresh=on They are always on. Is there any way to tell what page(s) is using up all the memory?
Comment 6•10 years ago
|
||
about:memory
Reporter | ||
Comment 7•10 years ago
|
||
about:memory report
Reporter | ||
Comment 8•10 years ago
|
||
It got to 1.5 GB and slowed to a crawl again. Here is the process tree: Main Process Explicit Allocations 1,143.38 MB (100.0%) -- explicit ├────385.14 MB (33.68%) -- window-objects │ ├──233.81 MB (20.45%) -- top(chrome://browser/content/browser.xul, id=3) │ │ ├──200.19 MB (17.51%) -- js-zone(0x1098a4800) │ │ │ ├──137.48 MB (12.02%) -- strings │ │ │ │ ├───76.92 MB (06.73%) ++ (1901 tiny) │ │ │ │ └───60.56 MB (05.30%) -- string(<non-notable strings>) │ │ │ │ ├──42.24 MB (03.69%) ── malloc-heap │ │ │ │ └──18.32 MB (01.60%) ── gc-heap │ │ │ ├───54.82 MB (04.79%) ── unused-gc-things │ │ │ └────7.89 MB (00.69%) ++ (6 tiny) │ │ └───33.61 MB (02.94%) -- active │ │ ├──30.06 MB (02.63%) -- window(chrome://browser/content/browser.xul) │ │ │ ├──15.35 MB (01.34%) -- dom │ │ │ │ ├──14.82 MB (01.30%) ── element-nodes │ │ │ │ └───0.53 MB (00.05%) ++ (4 tiny) │ │ │ └──14.70 MB (01.29%) ++ (4 tiny) │ │ └───3.56 MB (00.31%) ++ (6 tiny) │ ├───70.72 MB (06.18%) -- top(none)/detached │ │ ├──67.97 MB (05.94%) -- window(chrome://browser/content/browser.xul) │ │ │ ├──44.89 MB (03.93%) -- dom │ │ │ │ ├──43.38 MB (03.79%) ── element-nodes [3] │ │ │ │ └───1.51 MB (00.13%) ++ (4 tiny) │ │ │ ├──23.03 MB (02.01%) ++ js-compartment([System Principal], about:blank) │ │ │ └───0.04 MB (00.00%) ++ (2 tiny) │ │ └───2.75 MB (00.24%) ++ (3 tiny) │ ├───30.05 MB (02.63%) -- top(http://online.wsj.com/home-page?refresh=on, id=15) │ │ ├──19.81 MB (01.73%) -- active │ │ │ ├──18.65 MB (01.63%) ++ window(http://online.wsj.com/home-page?refresh=on) │ │ │ └───1.16 MB (00.10%) ++ (2 tiny) │ │ └──10.24 MB (00.90%) ++ (2 tiny) │ ├───26.07 MB (02.28%) ++ (10 tiny) │ └───24.49 MB (02.14%) -- top(http://www.wunderground.com/radar/radblast.asp?ID=MRX, id=33) │ ├──16.23 MB (01.42%) -- active │ │ ├──13.29 MB (01.16%) ++ window(http://www.wunderground.com/radar/radblast.asp?ID=MRX) │ │ └───2.94 MB (00.26%) ++ (3 tiny) │ └───8.26 MB (00.72%) ++ js-zone(0x126145800) ├────304.04 MB (26.59%) -- js-non-window │ ├──259.52 MB (22.70%) -- zones │ │ ├──137.49 MB (12.02%) -- zone(0x10624e000) │ │ │ ├───50.04 MB (04.38%) ++ (378 tiny) │ │ │ ├───49.97 MB (04.37%) ── unused-gc-things │ │ │ └───37.48 MB (03.28%) -- strings │ │ │ ├──28.38 MB (02.48%) -- string(<non-notable strings>) │ │ │ │ ├──24.66 MB (02.16%) ── gc-heap │ │ │ │ └───3.72 MB (00.33%) ── malloc-heap │ │ │ └───9.10 MB (00.80%) ++ (57 tiny) │ │ ├───50.39 MB (04.41%) -- zone(0x11b90e800) │ │ │ ├──34.25 MB (03.00%) ── unused-gc-things │ │ │ ├──14.46 MB (01.26%) ++ strings │ │ │ └───1.68 MB (00.15%) ++ (5 tiny) │ │ ├───25.84 MB (02.26%) -- zone(0x11e039800) │ │ │ ├──17.78 MB (01.56%) ── unused-gc-things │ │ │ └───8.05 MB (00.70%) ++ (6 tiny) │ │ ├───25.37 MB (02.22%) -- zone(0x129a2c000) │ │ │ ├──17.68 MB (01.55%) ── unused-gc-things │ │ │ └───7.70 MB (00.67%) ++ (6 tiny) │ │ ├───16.11 MB (01.41%) -- zone(0x106248800) │ │ │ ├──15.84 MB (01.39%) ++ strings │ │ │ └───0.28 MB (00.02%) ++ (4 tiny) │ │ └────4.33 MB (00.38%) ++ (7 tiny) │ ├───36.02 MB (03.15%) -- runtime │ │ ├──14.05 MB (01.23%) ── script-data │ │ ├──12.24 MB (01.07%) ++ script-sources │ │ └───9.73 MB (00.85%) ++ (11 tiny) │ └────8.50 MB (00.74%) ++ gc-heap ├────186.01 MB (16.27%) -- add-ons │ ├───93.75 MB (08.20%) -- {35d6291e-1d4b-f9b4-c52f-77e6410d1326} │ │ ├──89.70 MB (07.84%) -- window-objects │ │ │ ├──78.50 MB (06.87%) -- top(chrome://browser/content/browser.xul, id=3)/active/window(chrome://ebates/content/background.html)/js-compartment([System Principal], chrome://ebates/content/background.html) │ │ │ │ ├──49.40 MB (04.32%) -- objects │ │ │ │ │ ├──47.30 MB (04.14%) -- gc-heap │ │ │ │ │ │ ├──27.84 MB (02.43%) ── ordinary [46] │ │ │ │ │ │ ├──12.40 MB (01.08%) ── function [46] │ │ │ │ │ │ └───7.06 MB (00.62%) ── dense-array [46] │ │ │ │ │ └───2.10 MB (00.18%) ++ (2 tiny) │ │ │ │ ├──25.41 MB (02.22%) -- shapes │ │ │ │ │ ├──16.08 MB (01.41%) ++ gc-heap │ │ │ │ │ └───9.32 MB (00.82%) ++ malloc-heap │ │ │ │ └───3.70 MB (00.32%) ++ (4 tiny) │ │ │ └──11.19 MB (00.98%) ++ (2 tiny) │ │ └───4.05 MB (00.35%) ++ js-non-window/zones/zone(0x10624e000)/compartment([System Principal], [anonymous sandbox] (from: chrome://ebates/content/framework.js:234)) │ ├───59.32 MB (05.19%) -- DealHound-by-Savings.com@jetpack/js-non-window/zones │ │ ├──48.02 MB (04.20%) -- zone(0x10624e000) │ │ │ ├──29.72 MB (02.60%) ++ (120 tiny) │ │ │ └──18.30 MB (01.60%) -- compartment([System Principal], resource://gre/modules/commonjs/sdk/deprecated/traits-worker.js (from: resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///Users/jar/Library/Application%20Support/Firefox/Profiles/2o30y6ny.test/extensions/DealHound-by-Savings.com@jetpack.xpi!/bootstrap.js -> resource://gre/modules/commonjs/toolkit/loader.js:232)) │ │ │ ├──13.21 MB (01.15%) ++ objects │ │ │ └───5.10 MB (00.45%) ++ (3 tiny) │ │ └──11.30 MB (00.99%) ++ (7 tiny) │ ├───18.34 MB (01.60%) ++ (9 tiny) │ └───14.59 MB (01.28%) -- support@lastpass.com │ ├──13.58 MB (01.19%) -- js-non-window/zones/zone(0x10624e000) │ │ ├──12.56 MB (01.10%) ++ compartment([System Principal], file:///Users/jar/Library/Application%20Support/Firefox/Profiles/2o30y6ny.test/extensions/support@lastpass.com/components/lastpass.js) │ │ └───1.02 MB (00.09%) ++ (17 tiny) │ └───1.01 MB (00.09%) ++ (2 tiny) ├────142.61 MB (12.47%) ── heap-unclassified ├─────76.30 MB (06.67%) -- heap-overhead │ ├──74.18 MB (06.49%) ── waste │ └───2.11 MB (00.18%) ++ (2 tiny) ├─────37.20 MB (03.25%) ++ (20 tiny) └─────12.09 MB (01.06%) ++ storage Other Measurements 67.54 MB (100.0%) -- decommitted ├──61.34 MB (90.82%) -- js-non-window │ ├──61.34 MB (90.82%) ── gc-heap/decommitted-arenas │ └───0.00 MB (00.00%) ── runtime/gc/nursery-decommitted ├───4.41 MB (06.52%) -- workers/workers() │ ├──1.52 MB (02.24%) -- worker(resource:///modules/sessionstore/SessionWorker.js, 0x108f6e800) │ │ ├──1.52 MB (02.24%) ── gc-heap/decommitted-arenas │ │ └──0.00 MB (00.00%) ── runtime/gc/nursery-decommitted │ ├──1.46 MB (02.17%) -- worker(resource://gre/modules/PageThumbsWorker.js, 0x12b077400) │ │ ├──1.46 MB (02.17%) ── gc-heap/decommitted-arenas │ │ └──0.00 MB (00.00%) ── runtime/gc/nursery-decommitted │ └──1.43 MB (02.11%) -- worker(resource://gre/modules/osfile/osfile_async_worker.js, 0x110477400) │ ├──1.43 MB (02.11%) ── gc-heap/decommitted-arenas │ └──0.00 MB (00.00%) ── runtime/gc/nursery-decommitted └───1.80 MB (02.66%) -- add-ons/support@lastpass.com/workers/workers()/worker(chrome://lastpass/content/lpctypesworker.js, 0x11c6f7400) ├──1.80 MB (02.66%) ── gc-heap/decommitted-arenas └──0.00 MB (00.00%) ── runtime/gc/nursery-decommitted 73,228 (100.0%) -- event-counts ├──73,137 (99.88%) -- window-objects │ ├──51,589 (70.45%) -- top(none)/detached │ │ ├──51,456 (70.27%) ── window(chrome://browser/content/browser.xul)/dom/event-listeners [3] │ │ └─────133 (00.18%) ++ (2 tiny) │ ├──19,783 (27.02%) -- top(chrome://browser/content/browser.xul, id=3)/active │ │ ├──19,635 (26.81%) -- window(chrome://browser/content/browser.xul)/dom │ │ │ ├──19,632 (26.81%) ── event-listeners │ │ │ └───────3 (00.00%) ── event-targets │ │ └─────148 (00.20%) ++ (4 tiny) │ └───1,765 (02.41%) ++ (10 tiny) └──────91 (00.12%) ++ add-ons 778.40 MB (100.0%) -- js-main-runtime ├──445.10 MB (57.18%) -- zones │ ├──232.37 MB (29.85%) -- strings │ │ ├──162.08 MB (20.82%) ── malloc-heap │ │ └───70.29 MB (09.03%) ── gc-heap │ ├──188.61 MB (24.23%) ── unused-gc-things │ ├───16.07 MB (02.06%) ++ (5 tiny) │ └────8.04 MB (01.03%) -- type-objects │ ├──8.03 MB (01.03%) ── gc-heap │ └──0.01 MB (00.00%) ── malloc-heap ├──288.79 MB (37.10%) -- compartments │ ├──152.22 MB (19.56%) -- objects │ │ ├──126.77 MB (16.29%) -- gc-heap │ │ │ ├───51.10 MB (06.57%) ── ordinary │ │ │ ├───50.52 MB (06.49%) ── function │ │ │ ├───16.32 MB (02.10%) ── dense-array │ │ │ └────8.83 MB (01.13%) ── cross-compartment-wrapper │ │ ├───25.44 MB (03.27%) -- malloc-heap │ │ │ ├──15.94 MB (02.05%) ── slots │ │ │ ├───8.09 MB (01.04%) ── elements/non-asm.js │ │ │ └───1.42 MB (00.18%) ++ (3 tiny) │ │ └────0.00 MB (00.00%) ── non-heap/code/asm.js │ ├───93.81 MB (12.05%) -- shapes │ │ ├──55.48 MB (07.13%) -- gc-heap │ │ │ ├──26.91 MB (03.46%) -- tree │ │ │ │ ├──23.40 MB (03.01%) ── global-parented │ │ │ │ └───3.51 MB (00.45%) ── non-global-parented │ │ │ ├──18.34 MB (02.36%) ── base │ │ │ └──10.23 MB (01.31%) ── dict │ │ └──38.33 MB (04.92%) -- malloc-heap │ │ ├──17.44 MB (02.24%) ── compartment-tables │ │ ├──13.26 MB (01.70%) ── tree-tables │ │ └───7.64 MB (00.98%) ++ (2 tiny) │ ├───19.57 MB (02.51%) -- scripts │ │ ├──15.11 MB (01.94%) ── gc-heap │ │ └───4.47 MB (00.57%) ── malloc-heap/data │ ├───14.47 MB (01.86%) ── cross-compartment-wrapper-table │ └────8.72 MB (01.12%) ++ (7 tiny) ├───36.02 MB (04.63%) ── runtime └────8.50 MB (01.09%) -- gc-heap ├──8.50 MB (01.09%) ── chunk-admin └──0.00 MB (00.00%) ++ (2 tiny) 1,184 (100.0%) -- js-main-runtime-compartments ├──1,050 (88.68%) -- system │ ├────973 (82.18%) ++ (557 tiny) │ ├─────52 (04.39%) ── [System Principal], chrome://ebates/content/background.html [52] │ ├─────13 (01.10%) ── [System Principal], inProcessTabChildGlobal?ownedBy=chrome://browser/content/browser.xul [13] │ └─────12 (01.01%) ── [System Principal], about:blank [12] └────134 (11.32%) -- user ├───92 (07.77%) ── [Expanded Principal], [anonymous sandbox] (from: resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///Users/jar/Library/Application%20Support/Firefox/Profiles/2o30y6ny.test/extensions/DealHound-by-Savings.com@jetpack.xpi!/bootstrap.js -> resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/loader/sandbox.js:32) [92] └───42 (03.55%) ++ (34 tiny) 482.66 MB (100.0%) -- js-main-runtime-gc-heap-committed ├──294.05 MB (60.92%) -- used │ ├──279.12 MB (57.83%) ── gc-things │ ├────8.50 MB (01.76%) ── chunk-admin │ └────6.43 MB (01.33%) ── arena-admin └──188.61 MB (39.08%) -- unused ├──188.61 MB (39.08%) ── gc-things └────0.00 MB (00.00%) ++ (2 tiny) 102 (100.0%) -- message-manager └──102 (100.0%) -- referent ├───50 (49.02%) -- global-manager │ ├──50 (49.02%) ── strong │ └───0 (00.00%) ++ weak ├───48 (47.06%) -- parent-process-manager │ ├──48 (47.06%) ── strong │ └───0 (00.00%) ++ weak └────4 (03.92%) -- child-process-manager ├──4 (03.92%) ── strong └──0 (00.00%) ++ weak 1,552 (100.0%) -- observer-service └──1,552 (100.0%) -- referent ├──1,072 (69.07%) ── strong └────480 (30.93%) -- weak ├──479 (30.86%) ── alive └────1 (00.06%) ── dead 413 (100.0%) -- observer-service-suspect ├──215 (52.06%) ── referent(topic=xpcom-shutdown) └──198 (47.94%) ── referent(topic=memory-pressure) 538 (100.0%) -- preference-service └──538 (100.0%) -- referent ├──445 (82.71%) ── strong └───93 (17.29%) -- weak ├──93 (17.29%) ── alive └───0 (00.00%) ── dead 96.38 MB (100.0%) -- window-objects ├──66.68 MB (69.18%) -- dom │ ├──61.86 MB (64.18%) ── element-nodes │ ├───2.51 MB (02.61%) ── other │ ├───1.23 MB (01.27%) ── text-nodes │ └───1.08 MB (01.13%) ++ (4 tiny) ├──15.99 MB (16.59%) -- layout │ ├───7.64 MB (07.93%) ── style-sets │ ├───4.02 MB (04.17%) ── pres-shell │ ├───1.64 MB (01.70%) ── frames │ ├───1.63 MB (01.70%) ++ (4 tiny) │ └───1.05 MB (01.09%) ── style-contexts ├──13.68 MB (14.19%) ── style-sheets └───0.04 MB (00.04%) ── property-tables 0.30 MB ── canvas-2d-pixels 0.00 MB ── gfx-surface-quartz 0.00 MB ── gfx-textures 0 ── ghost-windows 571.66 MB ── heap-allocated 647.96 MB ── heap-committed 13.34% ── heap-overhead-ratio 0 ── host-object-urls 0.01 MB ── imagelib-surface-cache 15.58 MB ── js-main-runtime-temporary-peak 19,187 ── page-faults-hard 50,326,600 ── page-faults-soft 1,473.56 MB ── resident 4,608.65 MB ── vsize End of Main Process
Reporter | ||
Comment 9•10 years ago
|
||
It got to 2.4 GB today. Why isn't anyone looking at this? Dump is uploaded.
Reporter | ||
Comment 10•10 years ago
|
||
2.4 GB dump
Comment 11•9 years ago
|
||
I am pretty concerned that this old issue is still in status NEW !??? Originally, it has been reported against Firefox on OS X 10.8.4. I am having the same issue with Firefox 38 on Windows 7 64 bit. When browsing through flickr portfolios, with each new image page FF is quickly eating up memory, and never freeing this. As soon as the FF allocated memory (as displayed by Taskmgr) reaches 3 GB, FF stops responding. Overall RAM is not an issue, I have 20 gigs installed on my PC. With Chrome this does not happen. And interestingly, for every single image page in a flickr portfolio FF requires ~10x the memory compared to Chrome (eg. FF: ~25 MB, Chrome: ~2,5 MB). Exact figures of course depending on the size of the individual images. Please fix this. Regards Karsten
Comment 12•8 years ago
|
||
ludo, you use flickr quite extensively iirc. Do you see this issue?
Comment 13•8 years ago
|
||
(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #12) > ludo, you use flickr quite extensively iirc. Do you see this issue? Confirming : str : 1) open https://www.flickr.com/photos/lhirlimann/25682146753/in/photostream/ 2) click the ">" sign on the right of the picture , do so on many more pictures - memory goes up up and up 3) memory get's freed when the tab is closed.
Updated•8 years ago
|
Comment 14•8 years ago
|
||
We keep around decoded copies of all the images. They are unlocked (meaning they can be discarded) but I guess nothing actually triggers them to get discarded. Minimizing memory usage in about:memory does discard them as expected. I tested Firefox 25 and we don't keep around nearly as many decoded images, so I'm guessing the old DiscardTracker handled this case fine, but the new code that replaced it doesn't.
Comment 15•8 years ago
|
||
We should be discarding 60 seconds after no longer displaying a decoded image. Are you seeing that we're not discarding after 60? Or 60 is too long in this case?
Reporter | ||
Comment 16•8 years ago
|
||
The last few Firefox beta builds have fixed the memory leaks. Finally.
Comment 17•8 years ago
|
||
thanks for the update
Comment 18•8 years ago
|
||
(In reply to Jet Villegas (:jet) from comment #15) > We should be discarding 60 seconds after no longer displaying a decoded > image. Are you seeing that we're not discarding after 60? Or 60 is too long > in this case? We should, and we do. There's nothing wrong with the behavior I'm seeing right now. But apparently the builds we're looking at now don't have the bug, since (per comment 16) apparently we've inadvertently fixed this at some point. I'm a bit troubled that we don't know why it was happening. =\ It's worth noting that the theory that this was caused by us holding on to unlocked images, as mentioned in comment 14, doesn't really explain the symptoms. In addition to the aforementioned fact that we free those images after 60 seconds, they're also stored in volatile buffers on all OSes except Linux, which means that the OS can free them if the machine is running low on memory - and in particular, that it won't swap those pages to disk. Since it sounds like the reporter was experiencing issues with swapping, memory in unlocked volatile buffers is highly unlikely to be responsible. It would've been nice to know what actually *was* responsible. =\
Comment 19•8 years ago
|
||
I can still reproduce the exact same thing as in comment 14.
Comment 20•8 years ago
|
||
(In reply to Seth Fowler [:seth] [:s2h] from comment #18) > (In reply to Jet Villegas (:jet) from comment #15) > > We should be discarding 60 seconds after no longer displaying a decoded > > image. Are you seeing that we're not discarding after 60? Or 60 is too long > > in this case? > > We should, and we do. Not on my system. > There's nothing wrong with the behavior I'm seeing > right now. There is on my system. > But apparently the builds we're looking at now don't have the > bug, since (per comment 16) apparently we've inadvertently fixed this at > some point. Not from my point of view. > It's worth noting that the theory that this was caused by us holding on to > unlocked images, as mentioned in comment 14, doesn't really explain the > symptoms. It's not a theory it's a fact that I observed. > In addition to the aforementioned fact that we free those images > after 60 seconds, Now this is a theory and not a fact. The code may be designed to do that, but it's not happening. > they're also stored in volatile buffers on all OSes except > Linux, which means that the OS can free them if the machine is running low > on memory - and in particular, that it won't swap those pages to disk. I'm describing my symptoms, which is increased memory usage. It doesn't really matter if the original reporter was getting swapping or not. On my system I was getting increased memory usage that we shouldn't be getting. > It would've been nice to know what actually *was* responsible. =\ Well, since it's still happening so we can still find out!
Updated•8 years ago
|
Comment 21•8 years ago
|
||
This seems like a pretty bad usage of memory. Timothy, which platform are you reproducing on? Is there any chance you can repro on linux and record with rr?
Comment 22•8 years ago
|
||
(In reply to Eric Rahm [:erahm] from comment #21) > Timothy, which platform are you reproducing on? Is there any chance you can > repro on linux and record with rr? I'm on mac. I don't think this is hard to reproduce at all, I think I'm just the only one who has actually tried. rr might make it easier, but this problem is likely easy to track down without using the power of rr. It just needs someone to put a little time into it.
Comment 23•8 years ago
|
||
I have run across the same thing and have opened another ticket months ago: https://bugzilla.mozilla.org/show_bug.cgi?id=1228729. Maybe the details included can help to understand, reproduce and fix this issue - if it's not already fixed as comment 16 might suggest.
Comment 24•7 years ago
|
||
We're going to move this to P2 as it seems isolated to flickr.
Comment 25•2 years ago
|
||
I am still able to reproduce this on windows10 64bit using firefox latest nightly version 97.0a1 i reached a 1,1gb memory consumption with a 120photo album pressing the next button
Comment 26•2 years ago
|
||
I tried with the album in comment 0, the memory does increase. We keep around the decoded surfaces of the past images. However the images are "unlocked", which means that they can be purged at any time. Things that would cause these surfaces to get discarded: if there was a memory pressure event, if you navigate to a new page, if you hit the image surface cache limit (I think it's usualy 1 GB or 2 GB).
Comment 27•2 years ago
|
||
In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.
Updated•2 years ago
|
Description
•