Open Bug 904867 Opened 11 years ago Updated 2 years ago

Memory keeps going up and up in self-refreshing pages at flickr

Categories

(Core :: Graphics: ImageLib, defect, P3)

Product:
Core
Component:
Graphics: ImageLib
Version:
24 Branch
Platform:
x86
All
Type:
defect

Tracking

()

Status:
REOPENED

People

(Reporter: jamesrome, Unassigned)

Details

(Keywords: memory-leak, Whiteboard: [MemShrink:P2])

Attachments

(2 files)

memory-report.json.gz
234.42 KB, application/x-gzip
Details
memory-report7-29-14.json.gz
266.00 KB, application/x-gzip
Details
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)
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.
Severity: normal → major
Version: 23 Branch → 24 Branch
Summary: Memory keeps going up and up in Flickr → Memory keeps going up and up in self-refreshing pages
Component: General → Graphics
Product: Firefox → Core
Summary: Memory keeps going up and up in self-refreshing pages → Memory keeps going up and up in self-refreshing pages at flickr
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.
Now on OS X 10.9
(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
about:memory
Attached file memory-report.json.gz —
about:memory report
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
It got to 2.4 GB today. Why isn't anyone looking at this? Dump is uploaded.
2.4 GB dump
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
ludo, you use flickr quite extensively iirc. Do you see this issue?
Flags: needinfo?(ludovic)
(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.
Flags: needinfo?(ludovic)
Keywords: mlk
OS: Mac OS X → Windows Server 2008
Whiteboard: [MemShrink]
Component: Graphics → ImageLib
OS: Windows Server 2008 → All
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.
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?
Flags: needinfo?(ludovic)
The last few Firefox beta builds have fixed the memory leaks. Finally.
thanks for the update
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
(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. =\
I can still reproduce the exact same thing as in comment 14.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(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!
Flags: needinfo?(ludovic)
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?
Flags: needinfo?(tnikkel)
Whiteboard: [MemShrink] → [MemShrink:P1]
(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.
Flags: needinfo?(tnikkel)
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.
We're going to move this to P2 as it seems isolated to flickr.
Whiteboard: [MemShrink:P1] → [MemShrink:P2]

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

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).

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.

Severity: major → --
Severity: -- → S3
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: