Closed Bug 1241470 Opened 9 years ago Closed 8 years ago

Excessive CPU usage with 23 extensions present

Categories

(Firefox :: Untriaged, defect)

43 Branch
x86_64
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: hrdubwd, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: crash, Whiteboard: [memshrink:P3])

Attachments

(6 files, 7 obsolete files)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0 Build ID: 20160105164030 Steps to reproduce: I have 18 tabs pinned for very frequently used pages, and then may open anything from a few to many tabs in the course of my work (academic stuff). FF works well most of the time, but occasionally, but with monotonous regularity, it will go dead slow, consuming up to ~36% CPU, and so making FF use difficult to say the least, but also slowing the machine appreciably. I have let it run in this state for hours, and it never resolves. For comparison, the normal background tickover is around 2 or 3%, with occasional extra activity to say 10%. No problem with this at all. What seems to be happening is that memory is being shuffled around, or the contents thereof. The fact is that there is some 20 GB of free RAM, of which about 2 GB is being used (the numbers tick up and down continuously during this kind of event). I have put the cache into RAM on a virtual drive, along with all Windows temp files, so that should not be a problem - there is plenty of memory there as well, 20 GB!, no indexing, no compression. (After crashing and restarting to write this up, memory usage is around 1.3 GB, CPU usage around 2 - 5% - no problem to use.) This is under W7 Pro, 64-bit. It has been occurring for all of at least a few of the previous versions of FF. The only way to deal with it is to crash FF and reload, when after the loading settling down, all is well again, until some random point in the future. This has now happened many times. I have held off reporting thinking that I might identify the problem with a specific tab. I cannot.) I cannot see any similar reports of this kind of behaviour, except for some very specific single-tab problems, for example. Actual results: Excessive CPU usage slows FF to a crawl, and interferes with the machine generally, by causing slow responses. Expected results: Memory clean-up from time to time would not be a problem, but locked in a seemingly unending cycle is not functional.
OS: Unspecified → Windows 7
Hardware: Unspecified → x86_64
Please enter the address "about:memory?verbose" (with a lower-case "v") in the address bar and attach (using the "Add an attachment" link above) the output here.
Flags: needinfo?(hrdubwd)
Attached file memory-report.json.gz (obsolete) —
Flags: needinfo?(hrdubwd)
Is that what you need? It was not generated directly. Thanks.
It did it again - unusable ... had to restart.
Reporter, can you please attach the crash reports from about:crashes?
Flags: needinfo?(hrdubwd)
Keywords: crash
Whiteboard: [memshrink]
Chris, could you please take a look at the memory report attached in Comment #2?
Flags: needinfo?(cpeterson)
(In reply to Brindusa Tot from comment #5) > Reporter, can you please attach the crash reports from about:crashes? This event has never (noticeably) caused a crash. All crash reports have already been submitted anyway, and are not on this machine now. Further info: I have been exploring the effects of the pinned tabs. I found one that took a lot of CPU (http://www.speedtest.net/), but not in the sustained blocking fashion reported above. I have got it down to 2 possibles, but it seems that the condition only arises after a long period, and so far I have no definitive suggestions as to what is the cause. It might help if there was a way to see which tab was responsible for how much CPU use, but I cannot find anything reported - am I missing something (Chrome can do this, apparently). In the meantime I have put the cache into RAM, but with no obvious effect on the present problem (it was on a RAM disk before, as mentioned). I shall continue my testing, but it is necessarily slow!
Flags: needinfo?(hrdubwd)
I think Nicholas would be a better person to analyze about:memory reports. :)
Flags: needinfo?(cpeterson) → needinfo?(n.nethercote)
The memory usage doesn't seem out of the ordinary for that amount of tabs. At least one page seems to be using a ton of events, it's possible this is related to the high CPU usage. > 35,849 (100.0%) -- event-counts > ├──35,782 (99.81%) -- window-objects > │ ├──16,764 (46.76%) -- top(<anonymized-509>, id=509)/active > │ │ ├──16,755 (46.74%) -- window(<anonymized-1225>)/dom > │ │ │ ├──16,754 (46.73%) ── event-listeners > │ │ │ └───────1 (00.00%) ── event-targets > │ │ └───────9 (00.03%) ++ window(<anonymized-511>)/dom That page also correlates to the top memory consumer: > │ ├──135.03 MB (09.08%) -- top(<anonymized-509>, id=509) If it's not sensitive, can you let us know which site this is? Also we think switching to the 64-bit version of Firefox might help with memory pressure issues which could lead to high CPU usage as well. You can download that here: https://www.mozilla.org/firefox/all/
Flags: needinfo?(n.nethercote) → needinfo?(hrdubwd)
> Also we think switching to the 64-bit version of Firefox might help with > memory pressure issues which could lead to high CPU usage as well. You can > download that here: https://www.mozilla.org/firefox/all/ Yes, even if you have 20 GB of physical RAM, if you're running a 32-bit version of Firefox -- and you probably are, because that's the standard one -- then Firefox can use at most 2 or 4 GB of RAM, depending on the machine configuration. Also, judging by the memory reports you have quite a few extensions installed -- 14 or more? In our experience, when users have 10 or more extensions installed and they have high memory and/or CPU usage, it's one or more of the extensions that it the cause. Unfortunately the only way to confirm this is to selectively disable extensions in order to determine which one is at fault; then you can either report the problem to the extension author or decide if you can live without that extension. If you can post the full list of extensions (visit about:support, click on "Copy text to clipboard", paste in a comment here) we might be able to give you suggestions as to which ones are more likely to be causing problems.
Summary: Excessive CPU usage → Excessive CPU usage with 14+ extensions present
1. (In reply to Nicholas Nethercote [:njn] from comment #10) > Also, judging by the memory reports you have quite a few extensions ... Advice welcome, thanks. Application Basics ------------------ Name: Firefox Version: 43.0.4 Build ID: 20160105164030 Update Channel: release User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0 Multiprocess Windows: 0/2 (default: false) Safe Mode: false Crash Reports for the Last 3 Days --------------------------------- Report ID: bp-97b6f96e-6fdb-45b4-a5fa-199582160127 Submitted: 9 hours ago All Crash Reports Extensions ---------- Name: Adblock Plus Version: 2.7.1 Enabled: true ID: {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d} Name: Adobe Acrobat - Create PDF Version: 2.0 Enabled: true ID: web2pdfextension@web2pdf.adobedotcom Name: Blur Version: 5.3.1983 Enabled: true ID: donottrackplus@abine.com Name: Capture & Print Version: 0.1.9.3.1-signed Enabled: true ID: {146f1820-2b0d-49ef-acbf-d85a6986e10c} Name: Copy Plain Text 2 Version: 1.4 Enabled: true ID: copyplaintext@teo.pl Name: Duplicate in Tab Context Menu Version: 1.0.9.1-signed Enabled: true ID: DuplicateInTabContext@schuzak.jp Name: FireFTP Version: 2.0.26 Enabled: true ID: {a7c6cf7f-112c-4500-a7ea-39801a327e5f} Name: Flashblock Version: 1.5.20 Enabled: true ID: {3d7eb24f-2740-49df-8937-200b1cc08f8a} Name: HTTPS-Everywhere Version: 5.1.2 Enabled: true ID: https-everywhere-eff@eff.org Name: IE Tab 2 (FF 3.6+) Version: 5.12.12.1.1-signed Enabled: true ID: {1BC9BA34-1EED-42ca-A505-6D2F1A935BBB} Name: JavaScript Deobfuscator [this I will remove, recently added, does not do what I thought] Version: 2.0.2 Enabled: true ID: jsdeobfuscator@adblockplus.org Name: Lightbeam Version: 1.3.0.1-signed Enabled: true ID: jid1-F9UJ2thwoAm5gQ@jetpack Name: More About Version: 1.2.13 Enabled: true ID: MoreAbout@schuzak.jp Name: NoScript Version: 2.9.0.2 Enabled: true ID: {73a6fe31-595d-460b-a920-fcc0f8843232} Name: Padlock Version: 0.5.0.1-signed Enabled: true ID: {d09e32df-8610-4b33-b929-1e631b764130} Name: Privacy Badger Version: 1.0.5 Enabled: true ID: jid1-MnnxcxisBPnSXQ-eff@jetpack Name: PubPeer [only Added today] Version: 0.1.5.1-signed Enabled: true ID: jid1-rU2mNakSg7IiSQ@jetpack Name: Restart Version: 1.2.8 Enabled: true ID: Restart@schuzak.jp Name: SSL Version Control Version: 0.4.1-signed Enabled: true ID: jid1-ZM3BerwS6FsQAg@jetpack Name: The Camelizer - Price Tracker Version: 2.8.1 Enabled: true ID: izer@camelcamelcamel.com Name: Trustwave SecureBrowsing Version: 3.722.1-signed Enabled: true ID: securebrowsing@m86security.com Name: Vacuum Places Improved Version: 1.2.1-signed Enabled: true ID: VacuumPlacesImproved@lultimouomo-gmail.com Name: Xmarks Version: 4.3.7.1-signed Enabled: true ID: foxmarks@kei.com Name: Garmin Communicator Version: 4.1.0.1-signed Enabled: false ID: {195A3098-0BD5-4e90-AE22-BA1C540AFD1E} Name: Microsoft .NET Framework Assistant Version: 1.3.1.1-signed Enabled: false ID: {20a82645-c095-46ed-80e3-08825760534b} Name: selectivecookiedelete Version: 4.1.1-signed Enabled: false ID: selectivecookiedelete@siju.mathew Name: Tab Auto Reload Version: 2.0.17 Enabled: false ID: TabAutoReload@schuzak.jp Name: WOT Version: 20151208 Enabled: false ID: {a0d7ccb3-214d-498b-b4aa-0e8fda9a7bf7} Graphics -------- Adapter Description: NVIDIA Quadro 4000 Adapter Description (GPU #2): NVIDIA Quadro NVS 290 Adapter Drivers: nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um Adapter Drivers (GPU #2): nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um Adapter RAM: 2048 Adapter RAM (GPU #2): 256 Asynchronous Pan/Zoom: none Device ID: 0x06dd Device ID (GPU #2): 0x042f Direct2D Enabled: true DirectWrite Enabled: true (6.2.9200.17568) Driver Date: 2-3-2015 Driver Date (GPU #2): 2-3-2015 Driver Version: 9.18.13.4144 Driver Version (GPU #2): 9.18.13.4144 GPU #2 Active: false GPU Accelerated Windows: 2/2 Direct3D 11 (OMTC) Subsys ID: 078010de Subsys ID (GPU #2): 0000000c Supports Hardware H264 Decoding: Yes Vendor ID: 0x10de Vendor ID (GPU #2): 0x10de WebGL Renderer: Google Inc. -- ANGLE (NVIDIA Quadro 4000 Direct3D11 vs_5_0 ps_5_0) windowLayerManagerRemote: true AzureCanvasBackend: direct2d 1.1 AzureContentBackend: direct2d 1.1 AzureFallbackCanvasBackend: cairo AzureSkiaAccelerated: 0 Important Modified Preferences ------------------------------ accessibility.typeaheadfind: true accessibility.typeaheadfind.flashBar: 0 browser.cache.disk.capacity: 4194302 browser.cache.disk.enable: false browser.cache.disk.filesystem_reported: 1 browser.cache.disk.hashstats_reported: 1 browser.cache.disk.metadata_memory_limit: 2500 browser.cache.disk.parent_directory: R:\FFcache browser.cache.disk.smart_size_cached_value: 358400 browser.cache.disk.smart_size.enabled: false browser.cache.disk.smart_size.first_run: false browser.cache.disk.smart_size.use_old_max: false browser.cache.frecency_experiment: 4 browser.cache.memory.capacity: 4194302 browser.cache.memory.max_entry_size: 51200 browser.download.folderList: 2 browser.download.importedFromSqlite: true browser.download.manager.alertOnEXEOpen: true browser.history_expire_days.mirror: 180 browser.places.smartBookmarksVersion: 7 browser.search.useDBForOrder: true browser.sessionstore.restore_on_demand: false browser.sessionstore.upgradeBackup.latestBuildID: 20160105164030 browser.startup.homepage: about:home browser.startup.homepage_override.buildID: 20160105164030 browser.startup.homepage_override.mstone: 43.0.4 browser.tabs.warnOnClose: false browser.tabs.warnOnOpen: false browser.urlbar.userMadeSearchSuggestionsChoice: true dom.apps.reset-permissions: true dom.disable_window_open_feature.status: false dom.disable_window_status_change: false dom.ipc.plugins.enabled.npietab2.dll: true dom.max_chrome_script_run_time: 40 dom.max_script_run_time: 0 dom.mozApps.used: true dom.w3c_touch_events.expose: false extensions.lastAppVersion: 43.0.4 font.internaluseonly.changed: false general.useragent.extra.microsoftdotnet: ( .NET CLR 3.5.30729; .NET4.0E) gfx.blacklist.suggested-driver-version: 257.21 gfx.crash-guard.d3d11layers.appVersion: 43.0.4 gfx.crash-guard.d3d11layers.deviceID: 0x06dd gfx.crash-guard.d3d11layers.driverVersion: 9.18.13.4144 gfx.crash-guard.d3d11layers.feature-d2d: true gfx.crash-guard.d3d11layers.feature-d3d11: true gfx.crash-guard.glcontext.gfx.driver-init.direct3d11-angle: true gfx.crash-guard.glcontext.gfx.driver-init.webgl-angle: true gfx.crash-guard.glcontext.gfx.driver-init.webgl-angle-force-d3d11: false gfx.crash-guard.glcontext.gfx.driver-init.webgl-angle-force-warp: false gfx.crash-guard.glcontext.gfx.driver-init.webgl-angle-try-d3d11: true gfx.crash-guard.status.d3d11layers: 2 gfx.crash-guard.status.d3d9video: 2 gfx.crash-guard.status.glcontext: 2 gfx.direct3d.last_used_feature_level_idx: 0 gfx.driver-init.appVersion: 42.0 gfx.driver-init.deviceID: 0x06dd gfx.driver-init.driverVersion: 9.18.13.4144 gfx.driver-init.feature-d2d: true gfx.driver-init.feature-d3d11: true gfx.driver-init.status: 2 keyword.URL: https://uk.search.yahoo.com/search?fr=greentree_ff1&ei=utf-8&ilc=12&type=242154&p= media.directshow.enabled: false media.gmp-eme-adobe.abi: x86-msvc media.gmp-eme-adobe.lastUpdate: 1446718157 media.gmp-eme-adobe.version: 15 media.gmp-gmpopenh264.abi: x86-msvc media.gmp-gmpopenh264.lastUpdate: 1451577599 media.gmp-gmpopenh264.version: 1.5.3 media.gmp-manager.buildID: 20160105164030 media.gmp-manager.lastCheck: 1453905307 media.hardware-video-decoding.failed: false media.youtube-ua.override.to: 43 network.auth.allow-subresource-auth: 2 network.cookie.prefsMigrated: true network.http.keep-alive.timeout: 300 network.predictor.cleaned-up: true permissions.default.image: 0 places.database.lastMaintenance: 1453925907 places.history.expiration.transient_current_max_pages: 104858 places.history.expiration.transient_optimal_database_size: 139484692 places.last_vacuum: 1300785292 plugin.disable_full_page_plugin_for_types: application/vnd.adobe.xfdf,application/vnd.fdf,application/vnd.adobe.xdp+xml,chemical/x-chemdraw,audio/aiff,audio/x-aiff plugin.importedState: true plugin.state.flash: 1 plugin.state.npdeployjava: 0 plugin.state.nppdf: 2 print.print_printer: Lexmark E250d print.printer_Adobe_PDF.print_bgcolor: false print.printer_Adobe_PDF.print_bgimages: false print.printer_Adobe_PDF.print_colorspace: print.printer_Adobe_PDF.print_command: print.printer_Adobe_PDF.print_downloadfonts: false print.printer_Adobe_PDF.print_duplex: 896 print.printer_Adobe_PDF.print_edge_bottom: 0 print.printer_Adobe_PDF.print_edge_left: 0 print.printer_Adobe_PDF.print_edge_right: 0 print.printer_Adobe_PDF.print_edge_top: 0 print.printer_Adobe_PDF.print_evenpages: true print.printer_Adobe_PDF.print_footercenter: &D print.printer_Adobe_PDF.print_footerleft: &U print.printer_Adobe_PDF.print_footerright: &P print.printer_Adobe_PDF.print_headercenter: print.printer_Adobe_PDF.print_headerleft: print.printer_Adobe_PDF.print_headerright: print.printer_Adobe_PDF.print_in_color: true print.printer_Adobe_PDF.print_margin_bottom: 0.196527779102325 print.printer_Adobe_PDF.print_margin_left: 0.196527779102325 print.printer_Adobe_PDF.print_margin_right: 0.196527779102325 print.printer_Adobe_PDF.print_margin_top: 0.196527779102325 print.printer_Adobe_PDF.print_oddpages: true print.printer_Adobe_PDF.print_orientation: 0 print.printer_Adobe_PDF.print_page_delay: 50 print.printer_Adobe_PDF.print_pagedelay: 500 print.printer_Adobe_PDF.print_paper_data: 9 print.printer_Adobe_PDF.print_paper_height: 11.00 print.printer_Adobe_PDF.print_paper_name: print.printer_Adobe_PDF.print_paper_size_type: 0 print.printer_Adobe_PDF.print_paper_size_unit: 1 print.printer_Adobe_PDF.print_paper_width: 8.50 print.printer_Adobe_PDF.print_plex_name: print.printer_Adobe_PDF.print_resolution: 7168 print.printer_Adobe_PDF.print_resolution_name: print.printer_Adobe_PDF.print_reversed: false print.printer_Adobe_PDF.print_scaling: 0.90 print.printer_Adobe_PDF.print_shrink_to_fit: false print.printer_Adobe_PDF.print_to_file: false print.printer_Adobe_PDF.print_unwriteable_margin_bottom: 0 print.printer_Adobe_PDF.print_unwriteable_margin_left: 0 print.printer_Adobe_PDF.print_unwriteable_margin_right: 0 print.printer_Adobe_PDF.print_unwriteable_margin_top: 0 print.printer_Brother_FAX-2820_USB_Printer.print_bgcolor: false print.printer_Brother_FAX-2820_USB_Printer.print_bgimages: false print.printer_Brother_FAX-2820_USB_Printer.print_command: print.printer_Brother_FAX-2820_USB_Printer.print_downloadfonts: false print.printer_Brother_FAX-2820_USB_Printer.print_edge_bottom: 0 print.printer_Brother_FAX-2820_USB_Printer.print_edge_left: 0 print.printer_Brother_FAX-2820_USB_Printer.print_edge_right: 0 print.printer_Brother_FAX-2820_USB_Printer.print_edge_top: 0 print.printer_Brother_FAX-2820_USB_Printer.print_evenpages: true print.printer_Brother_FAX-2820_USB_Printer.print_footercenter: print.printer_Brother_FAX-2820_USB_Printer.print_footerleft: print.printer_Brother_FAX-2820_USB_Printer.print_footerright: print.printer_Brother_FAX-2820_USB_Printer.print_headercenter: print.printer_Brother_FAX-2820_USB_Printer.print_headerleft: print.printer_Brother_FAX-2820_USB_Printer.print_headerright: print.printer_Brother_FAX-2820_USB_Printer.print_in_color: true print.printer_Brother_FAX-2820_USB_Printer.print_margin_bottom: 0.236111119389534 print.printer_Brother_FAX-2820_USB_Printer.print_margin_left: 0.472222238779068 print.printer_Brother_FAX-2820_USB_Printer.print_margin_right: 0.472222238779068 print.printer_Brother_FAX-2820_USB_Printer.print_margin_top: 0.236111119389534 print.printer_Brother_FAX-2820_USB_Printer.print_oddpages: true print.printer_Brother_FAX-2820_USB_Printer.print_orientation: 0 print.printer_Brother_FAX-2820_USB_Printer.print_page_delay: 50 print.printer_Brother_FAX-2820_USB_Printer.print_pagedelay: 500 print.printer_Brother_FAX-2820_USB_Printer.print_paper_data: 9 print.printer_Brother_FAX-2820_USB_Printer.print_paper_height: 11.00 print.printer_Brother_FAX-2820_USB_Printer.print_paper_size_type: 0 print.printer_Brother_FAX-2820_USB_Printer.print_paper_size_unit: 1 print.printer_Brother_FAX-2820_USB_Printer.print_paper_width: 8.50 print.printer_Brother_FAX-2820_USB_Printer.print_reversed: false print.printer_Brother_FAX-2820_USB_Printer.print_scaling: 0.80 print.printer_Brother_FAX-2820_USB_Printer.print_shrink_to_fit: false print.printer_Brother_FAX-2820_USB_Printer.print_to_file: false print.printer_Brother_FAX-2820_USB_Printer.print_unwriteable_margin_bottom: 0 print.printer_Brother_FAX-2820_USB_Printer.print_unwriteable_margin_left: 0 print.printer_Brother_FAX-2820_USB_Printer.print_unwriteable_margin_right: 0 print.printer_Brother_FAX-2820_USB_Printer.print_unwriteable_margin_top: 0 print.printer_HP_Color_LaserJet_CP1215.print_bgcolor: false print.printer_HP_Color_LaserJet_CP1215.print_bgimages: false print.printer_HP_Color_LaserJet_CP1215.print_command: print.printer_HP_Color_LaserJet_CP1215.print_downloadfonts: false print.printer_HP_Color_LaserJet_CP1215.print_edge_bottom: 0 print.printer_HP_Color_LaserJet_CP1215.print_edge_left: 0 print.printer_HP_Color_LaserJet_CP1215.print_edge_right: 0 print.printer_HP_Color_LaserJet_CP1215.print_edge_top: 0 print.printer_HP_Color_LaserJet_CP1215.print_evenpages: true print.printer_HP_Color_LaserJet_CP1215.print_footercenter: print.printer_HP_Color_LaserJet_CP1215.print_footerleft: print.printer_HP_Color_LaserJet_CP1215.print_footerright: print.printer_HP_Color_LaserJet_CP1215.print_headercenter: print.printer_HP_Color_LaserJet_CP1215.print_headerleft: print.printer_HP_Color_LaserJet_CP1215.print_headerright: print.printer_HP_Color_LaserJet_CP1215.print_in_color: true print.printer_HP_Color_LaserJet_CP1215.print_margin_bottom: 0.236111119389534 print.printer_HP_Color_LaserJet_CP1215.print_margin_left: 0.472222238779068 print.printer_HP_Color_LaserJet_CP1215.print_margin_right: 0.472222238779068 print.printer_HP_Color_LaserJet_CP1215.print_margin_top: 0.236111119389534 print.printer_HP_Color_LaserJet_CP1215.print_oddpages: true print.printer_HP_Color_LaserJet_CP1215.print_orientation: 0 print.printer_HP_Color_LaserJet_CP1215.print_page_delay: 50 print.printer_HP_Color_LaserJet_CP1215.print_pagedelay: 500 print.printer_HP_Color_LaserJet_CP1215.print_paper_data: 9 print.printer_HP_Color_LaserJet_CP1215.print_paper_height: 11.00 print.printer_HP_Color_LaserJet_CP1215.print_paper_size_type: 0 print.printer_HP_Color_LaserJet_CP1215.print_paper_size_unit: 1 print.printer_HP_Color_LaserJet_CP1215.print_paper_width: 8.50 print.printer_HP_Color_LaserJet_CP1215.print_reversed: false print.printer_HP_Color_LaserJet_CP1215.print_scaling: 0.80 print.printer_HP_Color_LaserJet_CP1215.print_shrink_to_fit: false print.printer_HP_Color_LaserJet_CP1215.print_to_file: false print.printer_HP_Color_LaserJet_CP1215.print_unwriteable_margin_bottom: 0 print.printer_HP_Color_LaserJet_CP1215.print_unwriteable_margin_left: 0 print.printer_HP_Color_LaserJet_CP1215.print_unwriteable_margin_right: 0 print.printer_HP_Color_LaserJet_CP1215.print_unwriteable_margin_top: 0 print.printer_HP_LaserJet_1018.print_bgcolor: false print.printer_HP_LaserJet_1018.print_bgimages: false print.printer_HP_LaserJet_1018.print_colorspace: print.printer_HP_LaserJet_1018.print_command: print.printer_HP_LaserJet_1018.print_downloadfonts: false print.printer_HP_LaserJet_1018.print_duplex: 896 print.printer_HP_LaserJet_1018.print_edge_bottom: 0 print.printer_HP_LaserJet_1018.print_edge_left: 0 print.printer_HP_LaserJet_1018.print_edge_right: 0 print.printer_HP_LaserJet_1018.print_edge_top: 0 print.printer_HP_LaserJet_1018.print_evenpages: true print.printer_HP_LaserJet_1018.print_footercenter: &D print.printer_HP_LaserJet_1018.print_footerleft: &U print.printer_HP_LaserJet_1018.print_footerright: &P print.printer_HP_LaserJet_1018.print_headercenter: print.printer_HP_LaserJet_1018.print_headerleft: print.printer_HP_LaserJet_1018.print_headerright: print.printer_HP_LaserJet_1018.print_in_color: true print.printer_HP_LaserJet_1018.print_margin_bottom: 0.196527779102325 print.printer_HP_LaserJet_1018.print_margin_left: 0.196527779102325 print.printer_HP_LaserJet_1018.print_margin_right: 0.196527779102325 print.printer_HP_LaserJet_1018.print_margin_top: 0.196527779102325 print.printer_HP_LaserJet_1018.print_oddpages: true print.printer_HP_LaserJet_1018.print_orientation: 0 print.printer_HP_LaserJet_1018.print_page_delay: 50 print.printer_HP_LaserJet_1018.print_paper_data: 9 print.printer_HP_LaserJet_1018.print_paper_height: 11.00 print.printer_HP_LaserJet_1018.print_paper_name: print.printer_HP_LaserJet_1018.print_paper_size_type: 0 print.printer_HP_LaserJet_1018.print_paper_size_unit: 1 print.printer_HP_LaserJet_1018.print_paper_width: 8.50 print.printer_HP_LaserJet_1018.print_plex_name: print.printer_HP_LaserJet_1018.print_resolution: 7168 print.printer_HP_LaserJet_1018.print_resolution_name: print.printer_HP_LaserJet_1018.print_reversed: false print.printer_HP_LaserJet_1018.print_scaling: 0.60 print.printer_HP_LaserJet_1018.print_shrink_to_fit: false print.printer_HP_LaserJet_1018.print_to_file: false print.printer_HP_LaserJet_1018.print_unwriteable_margin_bottom: 0 print.printer_HP_LaserJet_1018.print_unwriteable_margin_left: 0 print.printer_HP_LaserJet_1018.print_unwriteable_margin_right: 0 print.printer_HP_LaserJet_1018.print_unwriteable_margin_top: 0 print.printer_HP_LaserJet_CP_1025nw.print_bgcolor: false print.printer_HP_LaserJet_CP_1025nw.print_bgimages: false print.printer_HP_LaserJet_CP_1025nw.print_colorspace: print.printer_HP_LaserJet_CP_1025nw.print_command: print.printer_HP_LaserJet_CP_1025nw.print_downloadfonts: false print.printer_HP_LaserJet_CP_1025nw.print_duplex: 896 print.printer_HP_LaserJet_CP_1025nw.print_edge_bottom: 0 print.printer_HP_LaserJet_CP_1025nw.print_edge_left: 0 print.printer_HP_LaserJet_CP_1025nw.print_edge_right: 0 print.printer_HP_LaserJet_CP_1025nw.print_edge_top: 0 print.printer_HP_LaserJet_CP_1025nw.print_evenpages: true print.printer_HP_LaserJet_CP_1025nw.print_footercenter: &D print.printer_HP_LaserJet_CP_1025nw.print_footerleft: &U print.printer_HP_LaserJet_CP_1025nw.print_footerright: &P print.printer_HP_LaserJet_CP_1025nw.print_headercenter: print.printer_HP_LaserJet_CP_1025nw.print_headerleft: print.printer_HP_LaserJet_CP_1025nw.print_headerright: print.printer_HP_LaserJet_CP_1025nw.print_in_color: true print.printer_HP_LaserJet_CP_1025nw.print_margin_bottom: 0.196527779102325 print.printer_HP_LaserJet_CP_1025nw.print_margin_left: 0.196527779102325 print.printer_HP_LaserJet_CP_1025nw.print_margin_right: 0.196527779102325 print.printer_HP_LaserJet_CP_1025nw.print_margin_top: 0.196527779102325 print.printer_HP_LaserJet_CP_1025nw.print_oddpages: true print.printer_HP_LaserJet_CP_1025nw.print_orientation: 0 print.printer_HP_LaserJet_CP_1025nw.print_page_delay: 50 print.printer_HP_LaserJet_CP_1025nw.print_paper_data: 9 print.printer_HP_LaserJet_CP_1025nw.print_paper_height: 11.00 print.printer_HP_LaserJet_CP_1025nw.print_paper_name: print.printer_HP_LaserJet_CP_1025nw.print_paper_size_type: 0 print.printer_HP_LaserJet_CP_1025nw.print_paper_size_unit: 1 print.printer_HP_LaserJet_CP_1025nw.print_paper_width: 8.50 print.printer_HP_LaserJet_CP_1025nw.print_plex_name: print.printer_HP_LaserJet_CP_1025nw.print_resolution: 7168 print.printer_HP_LaserJet_CP_1025nw.print_resolution_name: print.printer_HP_LaserJet_CP_1025nw.print_reversed: false print.printer_HP_LaserJet_CP_1025nw.print_scaling: 0.58 print.printer_HP_LaserJet_CP_1025nw.print_shrink_to_fit: true print.printer_HP_LaserJet_CP_1025nw.print_to_file: false print.printer_HP_LaserJet_CP_1025nw.print_unwriteable_margin_bottom: 0 print.printer_HP_LaserJet_CP_1025nw.print_unwriteable_margin_left: 0 print.printer_HP_LaserJet_CP_1025nw.print_unwriteable_margin_right: 0 print.printer_HP_LaserJet_CP_1025nw.print_unwriteable_margin_top: 0 print.printer_ImagePrinter.print_bgcolor: false print.printer_ImagePrinter.print_bgimages: false print.printer_ImagePrinter.print_colorspace: print.printer_ImagePrinter.print_command: print.printer_ImagePrinter.print_downloadfonts: false print.printer_ImagePrinter.print_duplex: 896 print.printer_ImagePrinter.print_edge_bottom: 0 print.printer_ImagePrinter.print_edge_left: 0 print.printer_ImagePrinter.print_edge_right: 0 print.printer_ImagePrinter.print_edge_top: 0 print.printer_ImagePrinter.print_evenpages: true print.printer_ImagePrinter.print_footercenter: &D print.printer_ImagePrinter.print_footerleft: &U print.printer_ImagePrinter.print_footerright: &P print.printer_ImagePrinter.print_headercenter: print.printer_ImagePrinter.print_headerleft: print.printer_ImagePrinter.print_headerright: print.printer_ImagePrinter.print_in_color: true print.printer_ImagePrinter.print_margin_bottom: 0.196527779102325 print.printer_ImagePrinter.print_margin_left: 0.196527779102325 print.printer_ImagePrinter.print_margin_right: 0.196527779102325 print.printer_ImagePrinter.print_margin_top: 0.196527779102325 print.printer_ImagePrinter.print_oddpages: true print.printer_ImagePrinter.print_orientation: 0 print.printer_ImagePrinter.print_page_delay: 50 print.printer_ImagePrinter.print_paper_data: 9 print.printer_ImagePrinter.print_paper_height: 11.00 print.printer_ImagePrinter.print_paper_name: print.printer_ImagePrinter.print_paper_size_type: 0 print.printer_ImagePrinter.print_paper_size_unit: 1 print.printer_ImagePrinter.print_paper_width: 8.50 print.printer_ImagePrinter.print_plex_name: print.printer_ImagePrinter.print_resolution: 7168 print.printer_ImagePrinter.print_resolution_name: print.printer_ImagePrinter.print_reversed: false print.printer_ImagePrinter.print_scaling: 0.60 print.printer_ImagePrinter.print_shrink_to_fit: true print.printer_ImagePrinter.print_to_file: false print.printer_ImagePrinter.print_unwriteable_margin_bottom: 0 print.printer_ImagePrinter.print_unwriteable_margin_left: 0 print.printer_ImagePrinter.print_unwriteable_margin_right: 0 print.printer_ImagePrinter.print_unwriteable_margin_top: 0 print.printer_Lexmark_E250d.print_bgcolor: false print.printer_Lexmark_E250d.print_bgimages: false print.printer_Lexmark_E250d.print_command: print.printer_Lexmark_E250d.print_downloadfonts: false print.printer_Lexmark_E250d.print_edge_bottom: 0 print.printer_Lexmark_E250d.print_edge_left: 0 print.printer_Lexmark_E250d.print_edge_right: 0 print.printer_Lexmark_E250d.print_edge_top: 0 print.printer_Lexmark_E250d.print_evenpages: true print.printer_Lexmark_E250d.print_footercenter: print.printer_Lexmark_E250d.print_footerleft: print.printer_Lexmark_E250d.print_footerright: print.printer_Lexmark_E250d.print_headercenter: print.printer_Lexmark_E250d.print_headerleft: print.printer_Lexmark_E250d.print_headerright: print.printer_Lexmark_E250d.print_in_color: true print.printer_Lexmark_E250d.print_margin_bottom: 0.236111119389534 print.printer_Lexmark_E250d.print_margin_left: 0.472222238779068 print.printer_Lexmark_E250d.print_margin_right: 0.472222238779068 print.printer_Lexmark_E250d.print_margin_top: 0.236111119389534 print.printer_Lexmark_E250d.print_oddpages: true print.printer_Lexmark_E250d.print_orientation: 0 print.printer_Lexmark_E250d.print_page_delay: 50 print.printer_Lexmark_E250d.print_pagedelay: 500 print.printer_Lexmark_E250d.print_paper_data: 9 print.printer_Lexmark_E250d.print_paper_height: 11.00 print.printer_Lexmark_E250d.print_paper_size_type: 0 print.printer_Lexmark_E250d.print_paper_size_unit: 1 print.printer_Lexmark_E250d.print_paper_width: 8.50 print.printer_Lexmark_E250d.print_reversed: false print.printer_Lexmark_E250d.print_scaling: 0.80 print.printer_Lexmark_E250d.print_shrink_to_fit: false print.printer_Lexmark_E250d.print_to_file: false print.printer_Lexmark_E250d.print_unwriteable_margin_bottom: 0 print.printer_Lexmark_E250d.print_unwriteable_margin_left: 0 print.printer_Lexmark_E250d.print_unwriteable_margin_right: 0 print.printer_Lexmark_E250d.print_unwriteable_margin_top: 0 privacy.clearOnShutdown.cache: false privacy.clearOnShutdown.cookies: false privacy.clearOnShutdown.downloads: false privacy.clearOnShutdown.formdata: false privacy.clearOnShutdown.history: false privacy.clearOnShutdown.sessions: false privacy.cpd.cache: false privacy.cpd.cookies: false privacy.cpd.extensions-betterprivacy: false privacy.cpd.formdata: false privacy.cpd.sessions: false privacy.donottrackheader.enabled: true privacy.donottrackheader.value: 1 privacy.sanitize.migrateFx3Prefs: true privacy.sanitize.timeSpan: 0 security.disable_button.openCertManager: false security.disable_button.openDeviceManager: false security.OCSP.disable_button.managecrl: false security.ssl.errorReporting.automatic: true security.warn_viewing_mixed: false storage.vacuum.last.index: 1 storage.vacuum.last.places.sqlite: 1453294100 Important Locked Preferences ---------------------------- JavaScript ---------- Incremental GC: true Accessibility ------------- Activated: false Prevent Accessibility: 0 Library Versions ---------------- NSPR Expected minimum version: 4.10.10 Version in use: 4.10.10 NSS Expected minimum version: 3.20.2 Basic ECC Version in use: 3.20.2 Basic ECC NSSSMIME Expected minimum version: 3.20.2 Basic ECC Version in use: 3.20.2 Basic ECC NSSSSL Expected minimum version: 3.20.2 Basic ECC Version in use: 3.20.2 Basic ECC NSSUTIL Expected minimum version: 3.20.2 Version in use: 3.20.2 Experimental Features ---------------------
Flags: needinfo?(hrdubwd)
Interesting to see that! print.printer_Lexmark_E250d.print print.printer_Brother_FAX-2820 print.printer_HP_Color_LaserJet_CP1215 - should not be present, uninstalled long ago! How do I remove the traces?
2. (In reply to Nicholas Nethercote [:njn] from comment #10) > > Also we think switching to the 64-bit version of Firefox might help ... OK, can try that later. Thanks.
This is most just a hunch, but I'd suggest disabling Trustwave SecureBrowsing, IE Tab 2, and maybe The Camelizer to begin with, to see if that helps. (In reply to Dr B W Darvell from comment #12) > Interesting to see that! > print.printer_Lexmark_E250d.print > print.printer_Brother_FAX-2820 > print.printer_HP_Color_LaserJet_CP1215 > - should not be present, uninstalled long ago! > How do I remove the traces? You can edit and delete preferences in about:config. It probably doesn't matter to have them there, though.
Summary: Excessive CPU usage with 14+ extensions present → Excessive CPU usage with 23 extensions present
3. (In reply to Eric Rahm [:erahm] from comment #9) > If it's not sensitive, can you let us know which site this is? Sure - how do I identify it? (Forgive the ignorance.)
(In reply to Nicholas Nethercote [:njn] from comment #14) > This is most just a hunch, but I'd suggest disabling Trustwave > SecureBrowsing, IE Tab 2, and maybe The Camelizer to begin with, to see if > that helps. Done. I'll see what happens tomorrow. > (In reply to Dr B W Darvell from comment #12) > > How do I remove the traces? > > You can edit and delete preferences in about:config. It probably doesn't > matter to have them there, though. Noted, thanks. Might as well, though, they are useless.
> > If it's not sensitive, can you let us know which site this is? > > Sure - how do I identify it? (Forgive the ignorance.) You'll have to re-measure, but with the "anonymize" box unchecked. The measurements won't be the same, but hopefully will be broadly similar so you can tell what site "<anonymized-509>" actually was.
(In reply to Nicholas Nethercote [:njn] from comment #17) > You'll have to re-measure, but with the "anonymize" box unchecked. The > measurements won't be the same, but hopefully will be broadly similar so you > can tell what site "<anonymized-509>" actually was. OK, will play tomorrow. Thanks.
1. Running FF-64, and have returned all extensions except Camelizer, with all previous pinned tabs in place. (I also added PrintEdit, to assist info. capture.) Normal business otherwise - quite a lot of tabs, diverse sites. BTW: The Plug-in container now seems to be much more efficient (watching with Process Explorer). 2. Now set cache to use 4 GB RAM - FF presently using total of 2.8 GB, plus 250 MB for plug-in container. (It was formerly set at 1 GB RAMdisk, although actually running at 2.0 - 2.3 GB) About:Cache memory Number of entries: 6801 Maximum storage size: 4194302 KiB Storage in use: 73605 KiB Storage disk location: none, only stored in memory 3. I have checked about:memory for event counts a few times but not found anything untoward; I cannot identify what caused the problem identified earlier, and no sign of a memory hog either. This is after a full day yesterday, and 4 h today (after "Sleep" - which is not a problem, then, either, I guess). Total CPU FF = 2 h 30 min, PIC = 30 min. 4. I have now enabled the Camelizer again (which to me was most suspicious), and will see if that has any effect. I'll report again next week. Q: Could I raise again the question of whether a per-tab CPU usage can be shown? That would help in such circs, I would imagine. Thanks.
> Q: Could I raise again the question of whether a per-tab CPU usage can be > shown? That would help in such circs, I would imagine. There's an experimental performance tool that finds expensive add-ons and tabs. You see it by typing "about:performance" into the address bar. However, it's currently only enabled on Nightly builds. I can't work out how to turn it on in release builds like 43. Yoric, can you tell us how to do it? Thank you.
Flags: needinfo?(dteller)
Sorry, it can't be turned on in a release build, it's #ifdef-away.
Flags: needinfo?(dteller)
Ok. Dr B W Darvell, if you're feeling motivated, you could try out a Nightly build (from https://nightly.mozilla.org/) and try using about:performance there. I'm not sure if Nightly uses a different profile to release Firefox. If it does, you'll need to re-install your add-ons in the Nightly profile, which I understand is annoying.
(In reply to Nicholas Nethercote [:njn] from comment #27) > Ok. Dr B W Darvell, if you're feeling motivated, To be honest, I have taken on so much that to add another task would be to the detriment of work. This thread was motivated because the problem was interfering. >#ifdef-away I take it that means disabled ... I'll just have to wait for it to appear, then. Anyway, I'll keep monitoring and let you know if the problem recurs. One thing that I notice now, though, on restarting - only pinned tabs were reloaded, all others had gone (I did not close them before shutting down). I did not change any setting (knowingly). It's not because of RAM cache, is it? I'll test later.
(In reply to Dr B W Darvell from comment #28) > One thing that I notice now, though, on restarting - only pinned tabs were > reloaded, all others had gone (I did not close them before shutting down). > I did not change any setting (knowingly). I have that problem too, sometimes. When you start the browser, it will show the about:home page, which should have a button underneath the search box that says something like "click here to restore tabs from the previous session". You can also go to the history menu option and try something like "restore previous session" and maybe it will bring those tabs back.
Thanks for that - I did not notice the button, and the restore option is now greyed out. I'll keep an eye on it.
A curious observa tion: Blank tab, Google search: https://www.google.co.uk/search?q=Sky+tv+view&ie=utf-8&oe=utf-8&gws_rd=cr&ei=XZ2vVoPeFcHSesTRsdAG#cns=0&gws_rd=cr - CPU activity then runs at around 12% continuously, with frequent excursions to 30%. Switch to a blank tab - almost immediately CPU becomes negligible 2 ~3%, with occasional other activity peaks, but nothing big. So: https://www.google.co.uk/search?q=dummy+search&ie=utf-8&oe=utf-8&gws_rd=cr&ei=0aSvVrqvFIa6Uf2VtZAC - which settles down after a few seconds some activity, but nothing problematic. Switch back to the Sky tab: steady activity again at 8 ~10%, but then stops when I switch away. Reproducible. I have Adblock Plus operating, so no ads show. I do not see many 'events' for this tab. Could it be that some search tabs could continue to be active when not in the foreground to have caused the initiating problem? Another example: Search on "Monet exhibition"- background soon very quiet ... switch the Sky search, busy again. Definitely something there.
I think I may have sussed it. I had set the cache in RAM at 4 GB, as I said above. All was fine - lots of tabs coming and going (about 30 open now). All the while I was monitoring the FF process window in Process Explorer. When Private Bytes in the Performance Graph tab reached 4 GB the CPU activity went high and stayed there for a while. It is now showing 4.2 GB ... Closing tabs makes no difference. It seems to me that the dumping of old cache items is not very efficient, and while there may be some improvement now using RAM over RAM disk, it still slowed me to a crawl for too long, and is running at a much higher than quiescent level still 20 minutes later. About:memory showed this: 100,598 (100.0%) -- event-counts ├──100,529 (99.93%) -- window-objects │ ├───63,427 (63.05%) -- top(none)/detached │ │ ├──44,821 (44.55%) ── window(about:memory)/dom/event-listeners [2] │ │ ├──16,598 (16.50%) ── window(chrome://browser/content/browser.xul)/dom/event-listeners [15] │ │ └───2,008 (02.00%) ++ (21 tiny) │ ├───14,824 (14.74%) ++ (79 tiny) (There is only one About: tab open.) I have not seen any tab make excessive calls other than that shown here (having checked several times). I shall now increase the cache allowed and see what happens.
Whiteboard: [memshrink] → [memshrink:P3]
Am I right in thinking that FF is not capable of running threads on other CPUs, or is there a thread limit, or overall throttling to limit the max. CPU% that it can take? I ask because no matter how busy it seems to peak now at around 30%, when it appears that there is plenty of CPU capacity remaining. If it were processor number-aware, and subbed off cache-maintenance to a separate thread, perhaps it would become more responsive? Or is all that totally naive because the system handles it? Thanks. Meanwhile, I have reached about 5 GB in the RAM cache, with occasional but annoying very slow response, but so far it has not gone into that extended unresponsive state.
Have we lost interest, chaps? Anyway, I have just found this: http://www.ghacks.net/2013/09/23/mozilla-launches-firefoxs-new-caching-back-end-nightly-version/ http://www.janbambas.cz/mozilla-firefox-new-http-cache-is-live/ and others. browser.cache.use_new_backend was "0" - I have now set it to "1". browser.cache.use_new_backend_temp is (still) True I get the impression that it should have been turned on by default by now. Is this a relevant setting, do you think? Are we missing anything else?
If you let Firefox manage the cache on its own (rather than setting your own custom values), does the CPU usage stay more stable over time?
No, that is certainly not my impression. It is even better now, I think, that I have allocated 8 GB. At one point I saw that memory usage had reached 7.2 GB, but I have not experienced the extreme slowness that I was complaining about at the outset. There are still episodes of higher activity, but they are relatively short and do not seem to interfere too much. Noticing that the memory content goes up and down (in small amounts) all the time, as the CPU activity varies as well, even though I am not doing anything, I get the impression that it was the major cache clean-up triggered when full that caused the huge and sustained CPU usage. Having just checked, I have about 84 tabs open (I know - but this is a consequence of the work I do), with the memory at about 2.2 GB. CPU variable, but no lock-ups.
Hi Darvell, thanks for hanging and providing all the details related to this issue. Unfortunately, problems like these are difficult to diagnose and debug. If you have some time, would you be willing to try collecting a profile to see if anything stands out there? The link below has directions for how to collect and submit a profile. https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler Thanks!
Hi, TFTM I did Tools | Web Developer | Performance, ran it until the buffer was full, and saved the profile - which gave a .json file (20 MB), no .sym (which is what I was expecting, based on my limited understanding of that page you linked. What am I missing? Thanks, BWD FF was very busy running that, and it still is ...
BTW: running that process and trying to save results in FF locking up for long periods. Oddly, since the last update (47.0.1), CPU usage seems to have dropped ... it could be a coincidence. BWD
(In reply to Dr B W Darvell from comment #39) > Oddly, since the last update (47.0.1), CPU usage seems to have dropped ... > it could be a coincidence. > > BWD Darvell, from your last comment my understanding is that this issue is not reproducible on the latest release version 47.0.1. Is this right?
Flags: needinfo?(hrdubwd)
No, I cannot say that. It appears to be a coincidence, that is all. I am still getting very slow occasions, but possibly less severe than when I started this. I am still looking forward to a multi-thread, multi-cpu version. ( https://bugzilla.mozilla.org/show_bug.cgi?id=392073 , https://wiki.mozilla.org/Electrolysis )
Hi Darvell, thanks again for you patience and for providing all the details related to this issue. If you have some time, would you be willing to try collecting a Cleopatra profile that hopefully would provide useful information for diagnose and debug. The link below has explicit directions for how to collect and submit a profile. https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem Thanks!
Hi, Sorry for the delay - I have been travelling. Sure, I'll give that a go, but in a day or so - a few jobs to do first. BWD
Apologies, it has not been possible to devote time to this yet. I'll have to return to the job in October. BWD
Hi Darvell, When time permits, could you please try to collect a Cleopatra profile? Thanks, Brindusa
I am marking this as Incomplete due to lack of response from reporter. Darvell, when have the time, please feel free to reopen it and provide the Cleopatra report if the issue is still reproducible on the latest Firefox version (current 49.0.2)
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
Hi, My apologies, I am just not able to do this for a while - snowed under and multitasking. I will endeavour to do this in about 10 - 12 days. Things should be clearer then. BWD
Hi, I cleared my work queue and started to try to do as requested. Immediately (even after restarting) I had dreadful delays - up to 40% CPU reported - that took ages to die down. I assume I was supposed load the Gecko Profiler extension - correct? So I tried a run, and received a warning in Cleopatra (after clicking the globe icon and clicking 'share') about my Profile being publicly visible. I cannot see what file is to be uploaded (i.e., I cannot check to see what content I am revealing). If it is supposed to be a json file, then there is no new one anywhere that I can see to correspond to allow me to check. Please advise: 1. Am I doing the right thing? 2. Where do I find the file that is to be uploaded. 3. Does this contain personal information of any kind that compromises my security in any way? 4. The profiler is said to collect a few seconds-worth of data - how many is a few? If I miss the behaviour we are trying to understand it will be pointless, of course. How long have I got? 5. I take it that the profiler is running continuously and should be disabled when not required, but then catching the action when FF is unresponsive is clearly not very practical. Thanks, BWD
Status: Resolved? Not having had a reply to my last I though you had just given up ... the problem has appeared to be less, but it has not gone away. Anyway, using Process Explorer, I have found an offending thread: firefox.exe|GetHandleVerifier This has been taking a full core's cycles for many minutes at a time lately - locking FF completely. I cannot see that I am doing anything in particular to trigger this, it appears to be a spontaneous matter. In fact, it is running continuously anyway, unevenly up to 20%, typically around 5% This is at one address (0x442c) while another instance (0x24d8) appears to be completely quiescent. (There is only one window.) Does this focus attention helpfully? It certainly seems to be the major process running. What I miss is a function that used to be present - suspending a tab. If this were feasible, it would be easier to identify an offending site or function. Unloading everything sequentially is just too time-consuming and interferes with work too much. Is that option still present? (There appears to be no add-on for this simple function. I have no need to save memory.) The only way I can see to achieve it is to click for reload and then immediately stop the process. Not very handy. Anyway, the few active tabs that I have tried this on have had no effect whatsoever on the offending thread. Thanks, BWD
I think a profile from the Gecko Profiler add-on is the best way to proceed here to determine what's happening. (In reply to Dr B W Darvell from comment #48) > Please advise: > 1. Am I doing the right thing? Presumably, yes. The profiler needs to be running during the bad performance behaviour, and then you need to dump the profile. The profile will be visible in a tab called "Cleopatra" (or perf.html for more modern versions of the add-on). Then you can share the profile with us. > 2. Where do I find the file that is to be uploaded. The file is in memory, but can be saved to disk from the Cleopatra / perf.html interface. The profile is uploaded to storage backed by Google App Engine. The source code that does this sharing for perf.html is here: https://github.com/devtools-html/perf.html/blob/c5b71f0869f95475f655d4bc57342f14f5aecd03/src/content/profile-store.js > 3. Does this contain personal information of any kind that compromises my > security in any way? The type of data that the profile will contain: 1) JS stacks which might include stack frames from inside your add-ons, so your add-on collection can be inferred 2) JS stacks for sites that are running JS - so the tabs you currently have open can possibly be inferred. 3) Version information on your OS, which version of Firefox you're running > 4. The profiler is said to collect a few seconds-worth of data - how many > is a few? If I miss the behaviour we are trying to understand it will be > pointless, of course. How long have I got? It has less to do with time, and more to do with space. There is a circular buffer that is recording the profile. I'd say in general though that a good rule of thumb is to assume that about 5 - 10 seconds of data will be collected. > 5. I take it that the profiler is running continuously and should be > disabled when not required, but then catching the action when FF is > unresponsive is clearly not very practical. Leaving the profiler running should be low cost. I suggest having it running constantly until you experience the behaviour, and then dump the profile as soon as possible.
Hi, Thanks for the reply. OK, so it can be left running, which is fine. But if FF has locked up for many minutes at a time (as it has now started to do in the last few days - and all due to that single process, it appears) how do I get in to dump the profile? I have to catch it within 5 or 10 s of it becoming responsive? That might be tricky. Ah - "Save to Local File" - correct? In a test just now, 13 Mb, no extension. Sound right? One last query: upload where? Is that at "Add an attachment (proposed patch, testcase, etc.)" on the top of this page? Thanks, BWD
(In reply to Dr B W Darvell from comment #51) > Hi, > Thanks for the reply. > > OK, so it can be left running, which is fine. But if FF has locked up for > many minutes at a time (as it has now started to do in the last few days - > and all due to that single process, it appears) how do I get in to dump the > profile? I have to catch it within 5 or 10 s of it becoming responsive? Unfortunately, yes. > That might be tricky. Unfortunately, yes. :( It might be simpler to attempt to bisect your add-ons to determine which (if any) are causing this problem. Disable half, and see if the problem goes away. If not, disable half of the remaining, etc, until you determine which add-on(s) are contributing to the issue, and then we can examine it in isolation. > > Ah - "Save to Local File" - correct? In a test just now, 13 Mb, no > extension. Sound right? > Yes, that sounds right. > One last query: upload where? Is that at "Add an attachment (proposed > patch, testcase, etc.)" on the top of this page? You can upload it to this bug if you'd like. Cleopatra / perf.html has a built-in to compress and upload the profile to that Google App Engine server, at which time it'll give you a URL you can post in this bug as an alternative.
Upload: OK - the "Share" button. (Not really feasible to check for 'personal' content in such a file!) Add-ons: I tried disabling but that had no clear outcome, certainly no finger of blame. The problem is that the effect is intermittent, and unpredictable. I could wait ages, and absence of evidence is not evidence of absence. I will try to catch an unreponsive period - I have a process window open from Process Explorer (Performance Graph) alongside while I work so that I can see what is happening a little more easily. If I can capture this well enough, I might then try disabling some add-ons, although this could perhaps only narrow the field somewhat, as perhaps you suggest. Anyway, would you expect the GetHandleVerifier to be running such as to block all other activity? The priority must be very high.
Well, it took a few days, but I fianlly caught an event - seized up for over 5 minutes. I think I have captured the necessary material: https://cleopatra.io/#report=8d3dd9ed2a64c1c2d889652a27fd99b7f474df94 I hope this helps, but I can confirm that it was GetHandleVerifier that was taking all available cycles. Please advise whether the file is usable. Thanks, BWD
Done it again - 20 min later, for about 6 minutes. https://cleopatra.io/#report=e385e632e8186bfd053d5cf72271400e670ed23b BWD
Thanks BWD, Looking at both of these profiles, I see indications of large amounts of cycle collection and garbage collection, which suggests to me that one or more of your add-ons are leaking. A memory report from about:memory would be the next step, in order to try to figure out where the memory is going.
Attached file memory-report.json.gz (obsolete) —
OK, thanks. New file uploaded. However, would it be most relevant when a freeze event occurs (which would have to be just after)? If there are options I should use for this, please advise.
BTW: what does GetHandleVerifier do and why is it running so much in the one instance - and the second apparently always quiet. (see comment 49) Incidentally, GC and CC in about:memory have no visible effect.
Flags: needinfo?(mconley)
Sorry - I do not understand: you need info from me?
No, sorry. I set the needinfo flag on myself to come back around to this and examine your about:memory report.
Oh, OK.
I really think the best thing we can try at this point is selectively disabling add-ons. After looking at your memory report the most likely culprits are Adblock Plus (which you might try upgrading to the latest version) and Blur, possibly NoScript. Anything related to tabs may be an issue (IE Tab, Auto reload tab, etc) as well. Generally we suggest a divide and conquer methodology: - Disable half your add-ons, if that fixes things re-enable half, repeat - If that doesn't fix things, disable half of the remaining add-ons, repeat Also it looks like you have about 115 tabs open, does that sound right? 115 tabs with 23 add-ons is very severe load, this could definitely lead to performance issues. Can you let us know which version of Firefox you're on at this point? Firefox 52 has quite a few memory leak fixes and other enhancements you might want to try out (it's currently Beta, will be promoted to release/ESR in a week). It also has e10s enabled which might help with overall performance. Interesting snippets: > ├──1,418.58 MB (37.92%) -- window-objects > │ ├────918.09 MB (24.54%) ++ (111 tiny) > │ ├────192.00 MB (05.13%) ++ top(<anonymized-62>, id=62) > │ ├────137.38 MB (03.67%) ++ top(<anonymized-60>, id=60) > │ ├─────66.48 MB (01.78%) ++ top(<anonymized-4948>, id=4948) > │ ├─────65.60 MB (01.75%) -- top(none) > │ │ ├──63.64 MB (01.70%) ++ ghost > │ │ └───1.97 MB (00.05%) ++ detached > │ └─────39.03 MB (01.04%) ++ top(<anonymized-14>, id=14) A lot of active windows, a few ghosts (often add-on related). This is the majority of the memory. > ├────666.40 MB (17.81%) -- js-non-window > │ ├──543.00 MB (14.52%) ++ zones > │ ├──106.06 MB (02.84%) ++ runtime > │ └───17.34 MB (00.46%) ++ gc-heap A lot dedicated to non-window zones. Much of this is add-on related. Recent versions have reduced overhead of Firefox's system zones, so a new version might help. > ├────618.51 MB (16.53%) -- layout > │ ├──617.88 MB (16.52%) ── rule-processor-cache > │ └────0.63 MB (00.02%) ++ (2 tiny) This looks like a bug, but could be poor interaction with ABP. For example my browser is using 0.62 MB with ~70 tabs. I'll file a follow up for this. > 5 (100.0%) -- ghost-windows > ├──1 (20.00%) ── <anonymized-1628> > ├──1 (20.00%) ── <anonymized-1639> > ├──1 (20.00%) ── <anonymized-2794> > ├──1 (20.00%) ── <anonymized-2938> > └──1 (20.00%) ── <anonymized-4642> 5 ghost windows, this indicates add-on issues. > 1,465 (100.0%) -- js-main-runtime-compartments > ├────772 (52.70%) ++ user > └────693 (47.30%) ++ system A *ton* of zones, this can cause large garbage collection and cycle collection pauses. I believe we've made improvements in recent versio ns.
(In reply to Eric Rahm [:erahm] from comment #63) > > 1,465 (100.0%) -- js-main-runtime-compartments > > ├────772 (52.70%) ++ user > > └────693 (47.30%) ++ system > > A *ton* of zones, this can cause large garbage collection and cycle > collection pauses. I believe we've made improvements in recent versio > ns. Bug 1324176 is one example of a fix in this area which landed in 53.
Thanks for all that. The version is 51.0.1 (64-bit) at the moment - and the next does sound better in many respects. I'll be patient. I do end up with lots of tabs open because of the nature of the work I do - much scientific literature searching, linked with lots of Google searches. I have many threads to pursue, interlinked in many ways, but also several projects on at once - which does not help. It is simply not possible to avoid this situation arising because I have to cross-check so much. However, I will try the selective disabling, as you suggest, and see whether that makes any difference. Again, though, I might have to wait for some time to see what is going on. AdBlock plus is 2.8.2 and no update is found on searching. I'll start with Blur at least, I am not convinced about that, and 10 others that I do not rely on much. The best thing to hope for is the problem recurs with what's left - that at least would be positive. Thanks again.
(In reply to Eric Rahm [:erahm] from comment #63) > > ├────618.51 MB (16.53%) -- layout > > │ ├──617.88 MB (16.52%) ── rule-processor-cache > > │ └────0.63 MB (00.02%) ++ (2 tiny) > > This looks like a bug, but could be poor interaction with ABP. For example > my browser is using 0.62 MB with ~70 tabs. I'll file a follow up for this. I filed bug 1343387 for this.
Attached file memory-report.json.gz (obsolete) —
After disabling 11 extensions.
I wonder whether you can see any significant changes in the new memory report. The memory usage (according to Process Explorer) has been pretty stable around 1.8 - 2.2 GB, and I have seen no freeze since (maybe not enough time ...). Meanwhile, the CPU usage appears to be much lower on average, althoug GetHandleVBerifier is still the busiest thread. Thanks.
(In reply to Dr B W Darvell from comment #68) > I wonder whether you can see any significant changes in the new memory > report. The memory usage (according to Process Explorer) has been pretty > stable around 1.8 - 2.2 GB, and I have seen no freeze since (maybe not > enough time ...). Meanwhile, the CPU usage appears to be much lower on > average, althoug GetHandleVBerifier is still the busiest thread. > > Thanks. The memory usage definitely looks better (note: you have fewer tabs open, so that helps too) and if you're not seeing freezes that's great! I still see a high 'rule-processor-cache' entry as well as ghost windows so it looks like you still have a misbehaving add-on enabled. Can you provide the add-on list from about:support and try disabling a few more?
I'll try diabling later, buit this is the current list: Adblock Plus 2.8.2 true {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d} Application Update Service Helper 1.0 true aushelper@mozilla.org Block site 1.1.8.1-signed.1-signed true {dd3d7613-0246-469d-bc65-2a3cc1668adc} Capture & Print 0.1.9.3.1-signed.1-signed true {146f1820-2b0d-49ef-acbf-d85a6986e10c} Diagnostics 1.0 true diagnostics@mozilla.org Disconnect 3.15.3.1-signed.1-signed true 2.0@disconnect.me Download Virus Checker 0.1.1 true {4785b360-ef55-4868-a385-c4ca829ba576} Flashblock 1.5.20 true {3d7eb24f-2740-49df-8937-200b1cc08f8a} geckoprofiler 1.16.25 true jid0-edalmuivkozlouyij0lpdx548bc@jetpack HTTP/2 and SPDY indicator 2.3 true spdyindicator@chengsun.github.com IE Tab 2 (FF 3.6+) 6.2.18.1 true {1BC9BA34-1EED-42ca-A505-6D2F1A935BBB} Multi-process staged rollout 1.7 true e10srollout@mozilla.org NoScript 2.9.5.3 true {73a6fe31-595d-460b-a920-fcc0f8843232} Padlock 0.5.0.1-signed.1-signed true {d09e32df-8610-4b33-b929-1e631b764130} Pocket 1.0.5 true firefox@getpocket.com Print Edit 17.9 true printedit@DW-dev Send HSTS Priming Requests 1.0 true hsts-priming@mozilla.org SHA-1 deprecation staged rollout 1.3 true disableSHA1rollout@mozilla.org Tree Style Tab 0.18.2016111701 true treestyletab@piro.sakura.ne.jp Tree Style Tabs Toplevel 1.0 true jid1-h4lBQP9pp2k89i@jetpack Trustwave SecureBrowsing 3.722.1-signed.1-signed true securebrowsing@m86security.com Vacuum Places Improved 1.2.1-signed.1-signed true VacuumPlacesImproved@lultimouomo-gmail.com Web Compat 1.0 true webcompat@mozilla.org Xmarks 4.4.1 true foxmarks@kei.com
Small update: I have disabled 5 more add-ons, and on restart there are zero ghosts: 45.13 MB ── d3d11-shared-textures 0.00 MB ── gfx-d2d-vram-draw-target 0.00 MB ── gfx-d2d-vram-source-surface 0.02 MB ── gfx-surface-win32 0.00 MB ── gfx-textures 0.00 MB ── gfx-textures-peak 0.00 MB ── gfx-tiles-waste 0 ── ghost-windows 250.05 MB ── gpu-committed 320.13 MB ── gpu-dedicated 48.65 MB ── gpu-shared 1,065.12 MB ── heap-allocated 1.00 MB ── heap-chunksize 1,170.00 MB ── heap-mapped 1 ── host-object-urls 1.45 MB ── imagelib-surface-cache-estimated-locked 1.75 MB ── imagelib-surface-cache-estimated-total 0 ── imagelib-surface-cache-overflow-count 9.21 MB ── js-main-runtime-temporary-peak 1,601.10 MB ── private 1,621.50 MB ── resident 1,598.04 MB ── resident-unique 19.77 MB ── system-heap-allocated 2,254.73 MB ── vsize 4,206,544.69 MB ── vsize-max-contiguous 18 ── webgl-buffer-count 15.75 MB ── webgl-buffer-memory 1 ── webgl-context-count 1 ── webgl-renderbuffer-count 8.62 MB ── webgl-renderbuffer-memory 20 ── webgl-shader-count 16 ── webgl-texture-count 26.08 MB ── webgl-texture-memory I will see whether any return when I get back to proper work. This item is still large (although smaller): ├────288.69 MB (19.84%) -- layout │ ├──288.16 MB (19.81%) ── rule-processor-cache │ └────0.53 MB (00.04%) -- (2 tiny) │ ├──0.49 MB (00.03%) ── style-sheet-cache │ └──0.04 MB (00.00%) ── style-sheet-service Are there other such specific pointers I can look at? Thanks.
I have just found this: 1 (100.0%) -- ghost-windows └──1 (100.0%) ── http://www.sigmaaldrich.com/catalog/product/sigma/32922?lang=en&region=GB This is unaffected by GC, CC or Memory minimization. So I went to the website and followed a number of random links, then closed the tab tree: no ghosts (i.e that previous one has disappeared). The exact same URL, opened and closed, also leaves no ghost. Curious. Also I have now: ├────459.00 MB (21.89%) -- layout │ ├──458.42 MB (21.86%) ── rule-processor-cache │ └────0.58 MB (00.03%) -- (2 tiny) │ ├──0.53 MB (00.03%) ── style-sheet-cache │ └──0.04 MB (00.00%) ── style-sheet-service 939 (100.0%) -- js-main-runtime-compartments ├──550 (58.57%) -- system │ ├──484 (51.54%) ++ (470 tiny) │ └───66 (07.03%) ── [System Principal], inProcessTabChildGlobal?ownedBy=chrome://browser/content/browser.xul [66] └──389 (41.43%) ++ user About 60 tabs.
Now isn't this peculiar -- these have emerged after the check above showed nothing: 20 (100.0%) -- ghost-windows ├───2 (10.00%) ── http://www.sigmaaldrich.com/catalog/product/sigma/32922?lang=en&region=GB [2] ├───2 (10.00%) ── http://www.sigmaaldrich.com/labware/labware-products.html?TablePage=12873256 [2] ├───2 (10.00%) ── http://www.sigmaaldrich.com/labware/learning-center.html [2] ├───2 (10.00%) ── http://www.sigmaaldrich.com/united-kingdom.html [2] ├───1 (05.00%) ── http://www.sigmaaldrich.com/analytical-chromatography/labware-and-equipment.html ├───1 (05.00%) ── http://www.sigmaaldrich.com/analytical-chromatography/titration/karl-fischer-titration.html ├───1 (05.00%) ── http://www.sigmaaldrich.com/catalog/product/aldrich/z555525?lang=en&region=GB ├───1 (05.00%) ── http://www.sigmaaldrich.com/customer-service/quality-systems.html ├───1 (05.00%) ── http://www.sigmaaldrich.com/customer-service/quality-systems/iso-certification.html ├───1 (05.00%) ── http://www.sigmaaldrich.com/labware/labware-products.html?TablePage=16683011 ├───1 (05.00%) ── http://www.sigmaaldrich.com/labware/labware-products.html?TablePage=17182794 ├───1 (05.00%) ── http://www.sigmaaldrich.com/labware/labware-products.html?TablePage=17187090 ├───1 (05.00%) ── http://www.sigmaaldrich.com/labware/labware-products.html?TablePage=9576922 ├───1 (05.00%) ── http://www.sigmaaldrich.com/labware/labware-products.html?TablePage=9582543 ├───1 (05.00%) ── http://www.sigmaaldrich.com/labware/learning-center/electrode-selection.html └───1 (05.00%) ── http://www.sigmaaldrich.com/site-level/email-tech-service-us.html?ProductNo=z555525&Brand=ALDRICH I shall do nothing deliberate that might affect these to see if they persist.
about:memory report for comment 74.
Steve S: Please file a new bug. It is very difficult to track what is going on with multiple people in a single bug. You clone the bug if you want, and put this bug in the see also field.
> Now isn't this peculiar -- these have emerged after the check above showed nothing: When you close a window (by closing a tab with a webpage open , for instance), it becomes top(none)/detached. Usually, it will go away soon after a few GC/CCs happen. If it stays in that state for a minute, then it becomes a ghost window. Generally speaking, if a window remains top(none)/detached after you do minimize memory usage, it is going to become a ghost window, so you don't really need to wait the full minute. It sounds like you have a way to reproduce a ghost window now. It would be good to figure out which addon is causing that (if any). I'd try disabling AdblockPlus and NoScript first. I fixed bug 1336811 in Firefox 52, which could be the same issue you are seeing. So you could try installing Firefox Beta, which will contain this fix, or wait until next week, when Firefox will be updated to version 52.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: INCOMPLETE → ---
OK, noted. I'll leave it for an hour or so, to see if any more emerge (I have just found that http://www.telegraph.co.uk/ does the same.) I'll then do the disabling systematically.
(In reply to Andrew McCreight [:mccr8] from comment #76) > Steve S: Please file a new bug. It is very difficult to track what is going > on with multiple people in a single bug. You clone the bug if you want, and > put this bug in the see also field. OK. It just seemed like the same issue, so I thought having my info might reveal some common elements that might help track down the cause. I'll probably just wait and see if this bug gets resolved.
(In reply to Steve S from comment #79) > > OK. It just seemed like the same issue, so I thought having my info might > reveal some common elements that might help track down the cause. I'll > probably just wait and see if this bug gets resolved. It is possible, and we appreciate the fact that you noticed that the symptoms are similar. Having said that, it's easier to effectively merge two bug reports (by marking one as a duplicate of another) than it is to split one bug report, so we prefer to err on the side of filing bugs separately.
Overnight (no changes made), the several ghosts for http://www.sigmaaldrich.com remained, as did those for http://www.telegraph.co.uk/. Opening a new tab and going to http://www.sigmaaldrich.com causes all the related ghosts to disappear. Likewise, opening a new tab for http://www.telegraph.co.uk/ causes those ghosts to go, immediately - zero count reported So I close both tabs. After about 2 minutes, ALL the previous ghosts reappear - with multiples ... 39 (100.0%) -- ghost-windows ├───6 (15.38%) ── http://www.sigmaaldrich.com/united-kingdom.html [6] ├───3 (07.69%) ── http://www.telegraph.co.uk/ [3] ├───2 (05.13%) ── http://www.sigmaaldrich.com/catalog/product/sigma/32922?lang=en&region=GB [2] ├───2 (05.13%) ── http://www.sigmaaldrich.com/labware/labware-products.html?TablePage=12873256 [2] ├───2 (05.13%) ── http://www.sigmaaldrich.com/labware/learning-center.html [2] ├───2 (05.13%) ── http://www.telegraph.co.uk/opinion/letters/ [2] ├───1 (02.56%) ── http://www.sigmaaldrich.com/analytical-chromatography/labware-and-equipment.html ├───1 (02.56%) ── http://www.sigmaaldrich.com/analytical-chromatography/titration/karl-fischer-titration.html ├───1 (02.56%) ── http://www.sigmaaldrich.com/catalog/product/aldrich/z555525?lang=en&region=GB ├───1 (02.56%) ── http://www.sigmaaldrich.com/customer-service/quality-systems.html ├───1 (02.56%) ── http://www.sigmaaldrich.com/customer-service/quality-systems/iso-certification.html ├───1 (02.56%) ── http://www.sigmaaldrich.com/customer-service/services/basic-research.html ├───1 (02.56%) ── http://www.sigmaaldrich.com/customer-service/services/facility-operations.html ├───1 (02.56%) ── http://www.sigmaaldrich.com/customer-service/services/mfg-production.html ├───1 (02.56%) ── http://www.sigmaaldrich.com/customer-service/services/regulatory-compliance.html ├───1 (02.56%) ── http://www.sigmaaldrich.com/labware/labware-products.html?TablePage=16683011 ├───1 (02.56%) ── http://www.sigmaaldrich.com/labware/labware-products.html?TablePage=17182794 ├───1 (02.56%) ── http://www.sigmaaldrich.com/labware/labware-products.html?TablePage=17187090 ├───1 (02.56%) ── http://www.sigmaaldrich.com/labware/labware-products.html?TablePage=9576922 ├───1 (02.56%) ── http://www.sigmaaldrich.com/labware/labware-products.html?TablePage=9582543 ├───1 (02.56%) ── http://www.sigmaaldrich.com/labware/learning-center/electrode-selection.html ├───1 (02.56%) ── http://www.sigmaaldrich.com/safc/bioprocess.html ├───1 (02.56%) ── http://www.sigmaaldrich.com/safc/testing-and-support-services.html ├───1 (02.56%) ── http://www.sigmaaldrich.com/site-level/email-tech-service-us.html?ProductNo=z555525&Brand=ALDRICH ├───1 (02.56%) ── http://www.telegraph.co.uk/football/2017/03/04/manchester-united-vs-bournemouth-premier-league-watch-live-score/ ├───1 (02.56%) ── http://www.telegraph.co.uk/news/uk/ ├───1 (02.56%) ── http://www.telegraph.co.uk/opinion/2017/03/01/telegraph-cartoons-march-2017/ └───1 (02.56%) ── http://www.telegraph.co.uk/opinion/cartoons/ Clearly, despite the memory report, the allocations persist, and are identifiable. So the memory report is failing somewhere to see what has been labelled. Is that another bug? I will now repeat the exercise with AdBlock disabled.
Restarted, and a random selection of links from the two root URLs, close all, two minutes later: 42 (100.0%) -- ghost-windows ├───8 (19.05%) ── http://www.sigmaaldrich.com/united-kingdom.html# [8] ├───5 (11.90%) ── http://gateway.answerscloud.com/sigmaaldrich/production/trigger/frameWorker.html?v=w0571rt [5] ├───3 (07.14%) ── http://www.telegraph.co.uk/news/#source=refresh [3] ├───2 (04.76%) ── http://www.sigmaaldrich.com/united-kingdom.html [2] ├───2 (04.76%) ── http://www.telegraph.co.uk/#source=refresh [2] ├───2 (04.76%) ── http://www.telegraph.co.uk/business/ [2] ├───2 (04.76%) ── http://www.telegraph.co.uk/content/dam/spark/component-assets/vendor/lightslider/css/lightslider.min.css [2] ├───2 (04.76%) ── http://www.telegraph.co.uk/content/dam/spark/component-assets/vendor/lightslider/js/lightslider.min.js [2] ├───2 (04.76%) ── http://www.telegraph.co.uk/culture/#source=refresh [2] ├───2 (04.76%) ── http://www.telegraph.co.uk/lifestyle/ [2] ├───2 (04.76%) ── http://www.telegraph.co.uk/money/consumer-affairs/new-1-coin-should-hoard-existing-1-coins/ [2] ├───2 (04.76%) ── http://www.telegraph.co.uk/opinion/#source=refresh [2] ├───2 (04.76%) ── http://www.telegraph.co.uk/sport/ [2] ├───1 (02.38%) ── http://shares.telegraph.co.uk/iframe/indiceRisersAndFallers2.php ├───1 (02.38%) ── http://shares.telegraph.co.uk/iframe/indices2.php ├───1 (02.38%) ── http://www.telegraph.co.uk/culture/ ├───1 (02.38%) ── http://www.telegraph.co.uk/opinion/ ├───1 (02.38%) ── http://www.telegraph.co.uk/travel/ └───1 (02.38%) ── https://cf-particle-html.eip.telegraph.co.uk/852113fc-8752-4c39-9efb-4c23191fadfe.html?ref=http://www.telegraph.co.uk/money/consumer-affairs/new-1-coin-should-hoard-existing-1-coins/&title=New%20%C2%A31%20coin:%20but%20should%20I%20hoard%20my%20existing%20%C2%A31%20coins? (BTW: I did not open 42 windows - only about 12 or 15.) I might as well try with all extensions disabled ...
... no ghosts. After 10 minutes, just to make sure. Repeat the tab openings and closings, still no ghosts. New memory report will be uploaded after this.
Attached file memory-report.json.gz (obsolete) —
Normal start. Open tab for top level domain only, and about 1.5 min after closing get this: 6 (100.0%) -- ghost-windows ├──4 (66.67%) ── http://www.sigmaaldrich.com/united-kingdom.html [4] ├──1 (16.67%) ── http://gateway.answerscloud.com/sigmaaldrich/production/trigger/frameWorker.html?v=w0571rt └──1 (16.67%) ── http://www.sigmaaldrich.com/ A minute later is this: 4 (100.0%) -- ghost-windows └──4 (100.0%) ── http://www.sigmaaldrich.com/united-kingdom.html [4] Repeat with the telegraph site: 6 (100.0%) -- ghost-windows ├──4 (66.67%) ── http://www.sigmaaldrich.com/united-kingdom.html [4] └──2 (33.33%) ── http://www.telegraph.co.uk/ [2] no other changes with time.
With NoScript disabled, for the two test URLs, after about 1 min of closing, there is this: 5 (100.0%) -- ghost-windows ├──2 (40.00%) ── http://www.sigmaaldrich.com/united-kingdom.html [2] ├──2 (40.00%) ── http://www.telegraph.co.uk/ [2] └──1 (20.00%) ── http://gateway.answerscloud.com/sigmaaldrich/production/trigger/frameWorker.html?v=w0571rt A minute later and there are none. This seems to be reproducible. At one point I had both an apparently active window and a ghost for the same item, presumably just a timing accident. Thoughts?
I re-enabled most extensions, except for Blur and Noscript. After opening and closing the two test sites, after a minute I get only one: 1 (100.0%) -- ghost-windows └──1 (100.0%) ── http://www.telegraph.co.uk/ So, try them again (the ghost disappears immediately on opening the URL). This time I get: 5 (100.0%) -- ghost-windows ├──3 (60.00%) ── http://www.telegraph.co.uk/ [3] └──2 (40.00%) ── http://www.sigmaaldrich.com/united-kingdom.html [2] I would surmise that NoScript is not to blame. Now for AdBlock again ...
Well, well. Adblock disabled, NoScript running: 7 (100.0%) -- ghost-windows ├──2 (28.57%) ── http://www.sigmaaldrich.com/united-kingdom.html [2] ├──1 (14.29%) ── http://www.telegraph.co.uk/ ├──1 (14.29%) ── http://www.telegraph.co.uk/content/dam/spark/component-assets/custom/non-iab/v2/main.2.5.js ├──1 (14.29%) ── http://www.telegraph.co.uk/content/dam/spark/component-assets/custom/non-iab/v2/main.2.6.css ├──1 (14.29%) ── http://www.telegraph.co.uk/content/dam/spark/component-assets/vendor/lightslider/css/lightslider.min.css └──1 (14.29%) ── http://www.telegraph.co.uk/content/dam/spark/component-assets/vendor/lightslider/js/lightslider.min.js but only on the second attempt. It is looking like it is an intermittent fault. Decidely erratic.
I found a couple more sites to produce the effect 3 (100.0%) -- ghost-windows ├──1 (33.33%) ── http://www.fco.gov.uk/en/about-the-fco/embassies-and-posts/find-an-embassy-overseas/middle-east-and-north-africa/kuwait ├──1 (33.33%) ── http://www.fco.gov.uk/en/travelling-and-living-overseas/travel-advice-by-country/middle-east-north-africa/kuwait └──1 (33.33%) ── https://www.wunderground.com/global/stations/40582.html but after 2 minutes, these had gone. Retrying all four sites, after a minute or so: 10 (100.0%) -- ghost-windows ├───2 (20.00%) ── http://www.sigmaaldrich.com/united-kingdom.html [2] ├───2 (20.00%) ── http://www.telegraph.co.uk/ [2] ├───2 (20.00%) ── https://www.gov.uk/government/organisations/foreign-commonwealth-office [2] ├───2 (20.00%) ── https://www.wunderground.com/ [2] ├───1 (10.00%) ── http://gateway.answerscloud.com/sigmaaldrich/production/trigger/frameWorker.html?v=w0571rt └───1 (10.00%) ── https://www.wunderground.com/MAR/ A couple of minutes later: 3 (100.0%) -- ghost-windows ├──1 (33.33%) ── https://www.gov.uk/government/organisations/foreign-commonwealth-office ├──1 (33.33%) ── https://www.wunderground.com/ └──1 (33.33%) ── https://www.wunderground.com/MAR/ later again: 2 (100.0%) -- ghost-windows ├──1 (50.00%) ── https://www.gov.uk/government/organisations/foreign-commonwealth-office └──1 (50.00%) ── https://www.wunderground.com/ and again, a minute or so: 1 (100.0%) -- ghost-windows └──1 (100.0%) ── https://www.wunderground.com/ ... and a minute or so later, all gone. It seems to have reached the point where I cannot sensibly diagnose what is going on because it would take many minutes every time I check an extension to be sure that it is not a passing state. Is there any way to track this automatically? If I am not reporting accurately, it clearly can be of no help to you. I now do not know how persistent all the previous ghosts have been as I have not waited ages each time. Advice?
At 80 minutes after closing the tab: 1 (100.0%) -- ghost-windows └──1 (100.0%) ── http://www.telegraph.co.uk/ I think that counts as persistent.
12 h later, still there.
Quite a bit of data to unpack here. I'm going to try to summarize: BWD: am I boiling this down correctly when I say that you're seeing permanent ghost windows on these sites (telegraph.co.uk for example) with NoScript enabled? If so, yeah, sounds like we've got a leak here. I wonder if this is related at all to bug 1326095, which should be fixed in tomorrow's release.
Flags: needinfo?(mconley)
I apologize - bug 1326095 is _not_ fixed in tomorrow's release. Bug 1336811, which was similar, is.
re: 92: Yes, apologies - I was trying v hard to nail it down, and failed. permanent: With and without NoScript (and, I thought, with and without AdBlock, but now doubts as I may not have checked for long enough). Will revisit these possibilities later. I have found another permanent (well, several hours, anyway) site in Dilbert: 3 (100.0%) -- ghost-windows ├──1 (33.33%) ── http://dilbert.com/ ├──1 (33.33%) ── http://www.sigmaaldrich.com/ └──1 (33.33%) ── http://www.telegraph.co.uk/ There must be something odd with these sites to cause this. I am trying to find more by checking lots of old bookmarks in batches. I have been through a hundred or so, so far. re: next release: I'll not have much chance to do anything for a few days, but will return to this when I can. Thanks.
Another site (out of a couple of hundred tested) that produces a persistent ghost: 5 (100.0%) -- ghost-windows ├──1 (20.00%) ── http://dilbert.com/ ├──1 (20.00%) ── http://www.sigmaaldrich.com/ ├──1 (20.00%) ── http://www.telegraph.co.uk/ ├──1 (20.00%) ── https://www.omni-inc.com/ └──1 (20.00%) ── https://www.omni-inc.com/dounce-tissue-grinder-1ml-11x48mm.html# What could it be about them that is special that causes this? Anyway, shutting down shortly.
I'm having trouble investigating dilbert.com because I hit an assertion. I'll check the other sites, though. Also be sure to check for updates to Firefox, as that should get you version 52 which has one or two fixes which might help.
Depends on: 1342877
Depends on: 1345260
I have just updated to FF52, loaded my test set of tabs, waited for completion, and then closed them all before running the memory check, when I get: +++ WARNING: the following values are negative or unreasonably large. explicit/js-non-window/gc-heap/unused-arenas js-main-runtime/gc-heap/(2 tiny)/unused-arenas js-main-runtime-gc-heap-committed/unused/arenas This indicates a defect in one or more memory reporters. The invalid values are highlighted. +++ The negative values were all -0.98 MB FF was then very unresponsive with a long (2 ~ 3 minutes or so) write to disk of over 200 MB, although CPU was only about 3%. Rerunning the memory check was then uneventful - no warnig, no disk activity of note. It was also much faster than on the previous version. I will do a rerun and see what happens.
Attached file memory-report.json.gz (obsolete) —
Attached file memory-report.json.gz (obsolete) —
Attachment #8846332 - Attachment is obsolete: true
Rerun ... 2 (100.0%) -- ghost-windows ├──1 (50.00%) ── http://dilbert.com/ └──1 (50.00%) ── https://blog.scopus.com/ but these then disappeared later. (I forgot to say, there were no ghosts in the previous run.) And again: 5 (100.0%) -- ghost-windows ├──2 (40.00%) ── http://www.sigmaaldrich.com/united-kingdom.html [2] ├──1 (20.00%) ── http://dilbert.com/ ├──1 (20.00%) ── http://www.hsc.edu.kw/jQueryNewsTicker/default.aspx └──1 (20.00%) ── http://www.telegraph.co.uk/#source=refresh after a couple of minutes, but these too disappeared. It may be that the problem has been fixed. I'll keep an eye on it, and especially the CPU usage. GetHandleVerifier is still dominant by a very long way. I have upload the current memory profile in case there is more to be seen.
I have tested a couple of hundred more sites, and none has left a persistent ghost. I think that particular aspect has now been sorted out. It still strikes me that there is a lot of CPU activity when nothing is happening. But I notice that the memory usage is not about 2.9 GB after minimizing memory, which only removed about 0.1 GB, when the start condition was about 2.1 - 2.2 GB. Still leaks?
A few clues --- I've had persistent performance issues in FFox as well, and found this thread by searching for "GetHandleVerifier", which I found was completely freezing FFox for many minutes at a time, and the only real solution is to restart FFox. I've had the identical problem on multiple PCs, in Win 7, 8, 8.1 10, 10-Ann. My PCs have been single processors with low RAM, and today, I'm running 16 GB with the fastest true Intel quad with SSD you can get. The problem still persists, regardless of hardware or OS. TABS and SESSION managers -- I had very few plugins in common with the OP. But, I have 60-100 tabs open as a rule, use a TREE type tab manager, AND a session manager, as well as ~25 other plugins. My CPU peaks at ~13% when freezing, which is probably typical for a single threaded process on a quad processor, and I'm only using about 3.5 GB of RAM. I use "Tab Tree" by Sergey Zelentsov instead though, ( https://addons.mozilla.org/en-US/firefox/addon/tab-tree/ ), instead of "Tree STYLE Tabs". However, I believe there's another PC I was using extensively, and it may have started showing the same problems, about the time I started using "trees", and I think that one was "Tree STYLE Tabs" plugin. So, seemingly common problem. (I haven't checked which process is hung on that PC). In "Tab Tree" plugin config page it states: "This extension was conceived as an alternative to Tree Style Tab to provide better performance, stability and usability." This is the first clue. Next, he also says: "Incompatible with TMP's session manager." Hmmm. Heard that before. But, it wasn't isolated to just TMP's session manager, it was any session manager. Searching on TMP session manager, I found this quote: "I do use TMP and used to use it on Windows before FF had its own session manager, but found the TMP session restore to cause my machine to perform poorly, a view I've seen echoed in other comments recently--but granted I haven't tried it myself with the latest FF and on this system. Do you have any experience with TMP's session manager--do you know whether it's stable and whether it slows the machine down much? – Philip Jan 3 '10 at 22:46" https://superuser.com/questions/90851/how-can-i-make-firefox-remember-my-session-while-still-clearing-the-browsing-his TMP's home page shows in the first few reviews, that it has performance problems: https://superuser.com/questions/90851/how-can-i-make-firefox-remember-my-session-while-still-clearing-the-browsing-his Here's another one that was SOLVED by disabling ONE of these: session manager - tab manager. https://support.mozilla.org/t5/Firefox/opens-with-tabs-from-previous-session/m-p/631957 I use "Session Manager" by Michael Kraft, ( http://sessionmanager.mozdev.org/documentation.html ), which I'm going to guess uses resources that conflict with ANY tab manager. Although It has it's own problems, it is essential to save and retrieve sessions that contain a ton of research about a specific subject. (Session Manager saves a separate file for the complete session, so I sometimes have GB's of files, which makes it nearly impossible to load that list!) Trees are essential for another reason--I need a LIST that I can see all my tabs, which is impossible / impractical by adding a bunch of rows, without seriously reducing my vertical available browser window. (Plus, good luck scanning a list of horizontal tabs, even if visible). -- There's a reason outlines are NEVER presented as a comma-delimited list--think about how dumb that would be. Yet, we think a ton of tabs should be horizontal, with 16 x 9 screens?? c'mon Devs--have you thought this through??) I really hope someone gets to the bottom of this. IMO, this is a common resource conflict issue, that can't be solved by the add-on DEVS. OTOH, we NEED these add-ons, or we wouldn't ever put up with the real pain of trying to coax FFox to perform even 50% of the time without crashing, or having us force a crash.
Interesting. For the record, I have never used an add-on session manager, and to be honest I have no idea what it is in FF either (sorry, guys!). A quick check: it has never been activated, deliberately at least. I use the horizontal tabs for very much the same reasons as awelsh, it seems: across the top is quite unusable, and tree structure essential - how I struggled before I found Tree Style Tabs! (Judging from the remarks on its page, I am not inclined now to test that alternative.) As for GetHandleVerifier, it remains the only process that churns away even when FF is quiescent - no loading, no refreshing, no animations. Always there are two instances, one with zero activity whenever I have looked. And nobody has responded to my enquiries about this, which is a little disappointing. Is it so banal and obvious? If this is just churning uselessly it would be good to tame it. Incidentally, I am not seeign any ghost windows (except for the brief intermediate period after closing one), and memory usage does not steadily creep up as it used to, so the changes for this version have been beneficial. Further to my comment 49: a way of suspending all activity (whatever it might be) in a tab would be a very useful way of diagnosing nwhere problems are occurring. Am I missing something or can this be reinstated? Thanks. +++++++ The usual stack for the GHV thread, almost always (while I am doing nothing): ntoskrnl.exe!memset+0x64a ntoskrnl.exe!KeWaitForMultipleObjects+0xd52 ntoskrnl.exe!KeWaitForSingleObject+0x19f ntoskrnl.exe!PoStartNextPowerIrp+0xbd4 ntoskrnl.exe!PoStartNextPowerIrp+0x186d ntoskrnl.exe!KeWaitForMultipleObjects+0xf5d ntoskrnl.exe!KeWaitForMultipleObjects+0x26a ntoskrnl.exe!NtWaitForSingleObject+0x40f ntoskrnl.exe!NtWaitForSingleObject+0x77e ntoskrnl.exe!KeSynchronizeExecution+0x3a23 ntdll.dll!ZwWaitForMultipleObjects+0xa KERNELBASE.dll!GetCurrentProcess+0x40 kernel32.dll!WaitForMultipleObjectsEx+0xb3 USER32.dll!GetScrollBarInfo+0x1dd USER32.dll!MsgWaitForMultipleObjectsEx+0x2e xul.dll!mozilla::net::LoadInfo::GetPrincipalToInherit+0xd1af xul.dll!mozilla::scache::PathifyURI+0x68f0 xul.dll!mozilla::net::LoadInfo::GetAboutBlankInherits+0x3ff3d xul.dll!mozilla::scache::PathifyURI+0x6766 xul.dll!mozilla::scache::PathifyURI+0x6b1f xul.dll!mozilla::scache::PathifyURI+0x60a2 xul.dll!mozilla::scache::PathifyURI+0x6423 xul.dll!mozilla::net::LoadInfo::GetLoadingDocument+0x20277 xul.dll!mozilla::net::LoadInfo::GetLoadingDocument+0x2023a xul.dll!XRE_GetProcessType+0x10b80 xul.dll!XRE_GetProcessType+0x10840 xul.dll!XRE_GetProcessType+0x107eb xul.dll!mozilla::net::LoadInfo::PrincipalToInherit+0x17787 xul.dll!XRE_InitCommandLine+0x23a xul.dll!XRE_main+0x55 firefox.exe+0x198a firefox.exe!GetHandleVerifier+0x1069 firefox.exe!GetHandleVerifier+0x4105 kernel32.dll!BaseThreadInitThunk+0xd ntdll.dll!RtlUserThreadStart+0x21
Well, well: 1 (100.0%) -- ghost-windows └──1 (100.0%) ── https://www.youtube.com/embed/usYTH_D0wxc?rel=0?ecver=2 - and I don't remember even looking at this! But of course, checking in FF makes the ghost go away, only to return - and persist overnight - when the window is closed again.
It is doing it again ... https://cleopatra.io/#report=e65016b645b47176f5566b17d9a53894e0e9b6e0 25 - 30% CPU, essentially locked out for several minutes at a time. No ghost windows, though, but 7.1 GB "private bytes"!
Flags: needinfo?(hrdubwd)
(In reply to Dr B W Darvell from comment #105) > It is doing it again ... > https://cleopatra.io/#report=e65016b645b47176f5566b17d9a53894e0e9b6e0 > 25 - 30% CPU, essentially locked out for several minutes at a time. > No ghost windows, though, but 7.1 GB "private bytes"! For this one, I see a lot of time being spent inside of DevTools... can I assume you had the Developer Tools open in some tab?
Flags: needinfo?(hrdubwd)
Not knowingly. I did have a 'logged to console' message at one point that it transpired I need to use DTs to view, but I thought I had closed all that as unhelpful. (I had apparently exceeded a Google maps API call limit of 25,000!) Does DT put that much load on? Bear in mind that this was not while I was trying to use any of it at that point (I think).
Flags: needinfo?(hrdubwd)
Hi Darvell, I know this is a hard one, and you helped developers with different investigations around it. Did you see any changes on the latest Release 53.0?
Hi, I have not noticed any major problems since the last report - no CPU-hogging that has prevented my doing anything at all. I keep an eye on it from time to time, although I did not pay attention as to when 53.0 was installed. Even with the profiler running on the offchance of catching a problem it has been seemingly unproblematic. I have also checked occasionally for ghost windows and found none that lasted more than a short while, as it seems is to be expected. And all this with many tabs loaded and much the same list of extensions. Overall, I have been unaffected and therefore happy enough. I will continue to make checks, just in case. Looking now at Process Explorer's graph, I see more I/O and variation in private bytes than previously, even though there is nothing obviously running (but who knows what is happening in non-viewed tabs?). Thanks for following up.
Darvell, thank you for all the support provided! For the time beeing and based on the previous comment, I will mark this bug Resolved-WFM, but please feel free to reopen it if this shows up again.
Status: REOPENED → RESOLVED
Closed: 8 years ago8 years ago
Resolution: --- → WORKSFORME
OK, thanks. I certainly have not seen any excessive CPU and lock-out for a while now, and no ghost windows. Mind you, this might be helped by the twin quad processors now! (Since a week ago, that is.) If I notice anything, I'll certainly come back to this thread. Thanks, BWD
(In reply to Brindusa Tot[:brindusat] from comment #110) I'm getting this issue - I found this bug searching for GetHandleVerifier. ProcessExplorer shows me it's stuck on 23% CPU for 2.5 trillion cycles (just over 20 minutes) It gives me this stack: ntoskrnl.exe!KeSynchronizeExecution+0x3f26 ntoskrnl.exe!KeWaitForMultipleObjects+0x10d7 ntoskrnl.exe!KeWaitForMultipleObjects+0xb3f ntoskrnl.exe!KeWaitForMutexObject+0x377 ntoskrnl.exe!PsGetCurrentThreadProcessId+0xa10 ntoskrnl.exe!KeSynchronizeExecution+0x44ef ntoskrnl.exe!KeSynchronizeExecution+0x4142 ntoskrnl.exe!KeSynchronizeExecution+0x3c8d xul.dll+0x6acc5a xul.dll+0x6accfa xul.dll+0xf4985 xul.dll+0xf4c39 xul.dll+0x6d104f Can't say I know any C++, but there's a possibly relevant comment in the source for ActiveVerifier::InstallVerifier https://dxr.mozilla.org/mozilla-central/source/security/sandbox/chromium/base/win/scoped_handle.cc#144 // If you are reading this, wondering why your process seems deadlocked, take // a look at your DllMain code and remove things that should not be done // there, like doing whatever gave you that nice windows handle you are trying // to store in a ScopedHandle.
(In reply to rob.swdev from comment #112) > (In reply to Brindusa Tot[:brindusat] from comment #110) > > I'm getting this issue - I found this bug searching for GetHandleVerifier. > ProcessExplorer shows me it's stuck on 23% CPU for 2.5 trillion cycles (just > over 20 minutes) > It gives me this stack: > ntoskrnl.exe!KeSynchronizeExecution+0x3f26 > ntoskrnl.exe!KeWaitForMultipleObjects+0x10d7 > ntoskrnl.exe!KeWaitForMultipleObjects+0xb3f > ntoskrnl.exe!KeWaitForMutexObject+0x377 > ntoskrnl.exe!PsGetCurrentThreadProcessId+0xa10 > ntoskrnl.exe!KeSynchronizeExecution+0x44ef > ntoskrnl.exe!KeSynchronizeExecution+0x4142 > ntoskrnl.exe!KeSynchronizeExecution+0x3c8d > xul.dll+0x6acc5a > xul.dll+0x6accfa > xul.dll+0xf4985 > xul.dll+0xf4c39 > xul.dll+0x6d104f > > > Can't say I know any C++, but there's a possibly relevant comment in the > source for ActiveVerifier::InstallVerifier > https://dxr.mozilla.org/mozilla-central/source/security/sandbox/chromium/ > base/win/scoped_handle.cc#144 > // If you are reading this, wondering why your process seems deadlocked, > take > // a look at your DllMain code and remove things that should not be done > // there, like doing whatever gave you that nice windows handle you are > trying > // to store in a ScopedHandle. Forgot to mention I have Firefox 53.0.3 64 bit.
On the same vbersion of FF, I have this at the moment: ntoskrnl.exe!memset+0x64a ntoskrnl.exe!KeWaitForMultipleObjects+0xd52 ntoskrnl.exe!KeWaitForMutexObject+0x19f ntoskrnl.exe!_misaligned_access+0xbd4 ntoskrnl.exe!_misaligned_access+0x186d ntoskrnl.exe!KeWaitForMultipleObjects+0xf5d ntoskrnl.exe!KeWaitForMultipleObjects+0x26a ntoskrnl.exe!NtWaitForSingleObject+0x40f ntoskrnl.exe!NtWaitForSingleObject+0x77e ntoskrnl.exe!KeSynchronizeExecution+0x3a23 ntdll.dll!ZwWaitForMultipleObjects+0xa KERNELBASE.dll!GetCurrentProcess+0x40 kernel32.dll!WaitForMultipleObjectsEx+0xb3 USER32.dll!GetScrollBarInfo+0x1dd USER32.dll!MsgWaitForMultipleObjectsEx+0x2e xul.dll+0x41b1f4 xul.dll+0xf6d52 xul.dll+0x74830d xul.dll+0xf6b0e xul.dll+0xf6edb xul.dll!workerlz4_compress+0x1381a xul.dll+0x22985a xul.dll+0x29dad8 some 2 ~ 7 % of CPU, continuous. The second instance of GetHandleVerifier mentioned a few times above is present at the moment. Has something changed? But it still seems to me to be odd that it runs all the time like this when there is minimal other activity. Nobody has said what it is for, despite requests. Other than the occasional autorefresh, is it not reasonable to expect a program to be quiescent when not in use? It may be an oversight as implied at 112 above.
Strangely, just now, on a laptop using Win7 32-bit, the same version of FF gave >>60% CPU for a long period - all down to the same source: GetHandleVerifier. Nothing else could be done while this was running. The was only the one instance present. (No ghost windows, only a few tabs open, nothing active particularly. Memory not a problem.) There is something weird in there. Could this be investigated, please? Thanks.
Doing it again, on the 64-bit machine - typing this is a struggle! GHV has 612,717,000,000,000 cycles logged! Kernel time 1 hour 56 min! Others I have spoken to complain about FF being slow - it is not just me.
(In reply to Dr B W Darvell from comment #116) > Doing it again, on the 64-bit machine - typing this is a struggle! GHV has > 612,717,000,000,000 cycles logged! Kernel time 1 hour 56 min! > Others I have spoken to complain about FF being slow - it is not just me. Can you please try to gather another performance profile while in this state using the newest version of the Gecko Profiler add-on, available at https://perf-html.io/ ?
Note that I believe you'll need to do this using the Nightly version of the browser.
Flags: needinfo?(hrdubwd)
I am not sure I can dedicate the time to do this, if not a standard set up. The events are erratic, and I do not know what triggers it. It has taken a long time for this to reoccur, and I am out a lot in the coming couple of weeks. That said, I cannot see that the Nightly is required - it has installed without hitch.
Flags: needinfo?(hrdubwd)
(In reply to Dr B W Darvell from comment #119) > That said, I cannot see that the Nightly is required - it has installed > without hitch. Yes, it will install - however, the information we get through the Profiler from Nightly is richer and more usable than what we get through the other channels because of how it's been configured at build time.
In that case, I am probably not going to be able to help. I cannot risk getting in a tangle with trial versions. But, tell me this, please: why does nobody say anything in response to the comments about GetHandleVerifier? Is this a stupid question? Am I missing something because I am not a programmer? Something that is so obvious that it is beneath contempt? Humour me, please: what does it do, and why does it need to run so much? 5 - 7% CPU (5 billion cycles a second!) when nearly everything else is at <0.01% CPU does seem very strange. Thanks.
(In reply to Dr B W Darvell from comment #121) > Humour me, please: what does it do, and why does it need to run so much? > 5 - 7% CPU (5 billion cycles a second!) when nearly everything else is at > <0.01% CPU does seem very strange. > I don't know what it does, exactly. Seems related to sandboxing, but I'm really not sure. Looks like bobowen touched the sandbox code around [1], so maybe he can give more insight. [1]: http://searchfox.org/mozilla-central/rev/66d9eb3103e429127c85a7921e16c5a02458a127/security/sandbox/chromium/base/win/scoped_handle.cc#139-147
Flags: needinfo?(bobowencode)
(In reply to Dr B W Darvell from comment #121) > But, tell me this, please: why does nobody say anything in response to the > comments about GetHandleVerifier? Is this a stupid question? Am I missing > something because I am not a programmer? Something that is so obvious that > it is beneath contempt? > Also, I apologize I hadn't answered this question directly earlier. I was so intent on getting a profile, I missed it despite you asking so many times. It's certainly not a stupid question, it's a perfectly valid one.
re #122: Ah ... OK, If the mentioned deadlock (or similar) is underlying this, i.e. a fault in webpage code [???], is there no way to detect this and bypass the problem? We can hope for a response from bobowen (but that has been there a long time, no? 2012). Error trapping used to be the thing to ensure when I was working in BASIC (yes, I know ...). It does look like a lot of looping is going on. re #123: OK, thank you. We can but hope for a definitive answer from someone else.
(In reply to Dr B W Darvell from comment #121) > In that case, I am probably not going to be able to help. I cannot risk > getting in a tangle with trial versions. > > But, tell me this, please: why does nobody say anything in response to the > comments about GetHandleVerifier? Is this a stupid question? Am I missing > something because I am not a programmer? Something that is so obvious that > it is beneath contempt? Not a stupid question (they rarely are) just things being typically confusing. :-) I haven't read too far down the bug (it's rather long), but I think you are seeing a thread in Process Explorer with a start address of something like firefox.exe!GetHandleVerifier+0x27ff. I'm pretty sure this is just down to not having the correct symbols. By the way, even though I think this is wrong, this is the start address of the thread not what it is doing now, you would need to look at the stack to see that. If I set up Process Explorer to use my symbol cache (which I use for VisualStudio and windbg) the thread's start address is firefox.exe!wmainCRTStartup. This is the main thread. So all this means is that whatever is taking a fairly steady percentage of CPU is happening on the main thread, which is not too surprising and would explain why Firefox isn't very responsive. You could try adding http://symbols.mozilla.org/firefox into the "Symbols Path:" for Process Explorer under Options->Configure Symbols... and then looking at the stack, but that never works very well for me. I don't generally set up Process Explorer to download from the online symbol store as it quite often locks up.
Flags: needinfo?(bobowencode)
Hi, Thanks for responding. 1. OK, thanks. 2. Start address is similar, yes. 3. Symbol cache: OK, done that. The stack (at a random point) shows: 0 ntoskrnl.exe!memset+0x64a 1 ntoskrnl.exe!KeWaitForMultipleObjects+0xd52 2 ntoskrnl.exe!KeWaitForMutexObject+0x19f 3 ntoskrnl.exe!_misaligned_access+0xbd4 4 ntoskrnl.exe!_misaligned_access+0x186d 5 ntoskrnl.exe!KeWaitForMultipleObjects+0xf5d 6 ntoskrnl.exe!KeWaitForMultipleObjects+0x26a 7 ntoskrnl.exe!NtWaitForSingleObject+0x40f 8 ntoskrnl.exe!NtWaitForSingleObject+0x77e 9 ntoskrnl.exe!KeSynchronizeExecution+0x3a23 10 ntdll.dll!ZwWaitForMultipleObjects+0xa 11 KERNELBASE.dll!GetCurrentProcess+0x40 12 kernel32.dll!WaitForMultipleObjectsEx+0xb3 13 USER32.dll!GetScrollBarInfo+0x1dd 14 USER32.dll!MsgWaitForMultipleObjectsEx+0x2e 15 xul.dll+0x41b1f4 16 xul.dll+0xf6d52 17 xul.dll+0x74830d 18 xul.dll+0xf6b0e 19 xul.dll+0xf6edb 20 xul.dll+0x41516e 21 xul.dll+0xf671f 22 xul.dll+0x4e5173 23 xul.dll+0x4e5136 24 xul.dll+0x4e4e1c 25 xul.dll+0x4e4adc 26 xul.dll+0x4e4a87 27 xul.dll+0x5ebe3b 28 xul.dll+0x644fbc 29 xul.dll+0x7ced39 30 firefox.exe+0x2a36 31 firefox.exe+0x1180 32 firefox.exe!GetHandleVerifier+0x2a3d 33 kernel32.dll!BaseThreadInitThunk+0xd 34 ntdll.dll!RtlUserThreadStart+0x21 lines 3 and 4 look ominous. Very similar a few minutes later: 0 ntoskrnl.exe!memset+0x64a 1 ntoskrnl.exe!KeWaitForMultipleObjects+0xd52 2 ntoskrnl.exe!KeWaitForMutexObject+0x19f 3 ntoskrnl.exe!_misaligned_access+0xbd4 4 ntoskrnl.exe!_misaligned_access+0x186d 5 ntoskrnl.exe!IoFreeErrorLogEntry+0x287 <snip> ... and again: 0 ntoskrnl.exe!memset+0x64a 1 ntoskrnl.exe!KeWaitForMultipleObjects+0xd52 2 ntoskrnl.exe!KeWaitForMutexObject+0x19f 3 ntoskrnl.exe!_misaligned_access+0xbd4 4 ntoskrnl.exe!_misaligned_access+0x186d 5 ntoskrnl.exe!IoFreeErrorLogEntry+0x287 6 xul.dll+0x27b270 7 xul.dll+0x27b082 8 xul.dll+0x753a85 9 xul.dll+0x27ac10 10 xul.dll+0x350ca6 11 xul.dll+0x27a202 12 xul.dll+0x3dd197 13 xul.dll+0x3dcf79 14 xul.dll+0x36230a 15 xul.dll+0x362b36 16 xul.dll+0xabb3b 17 xul.dll+0xab73f 18 xul.dll+0xf701b 19 xul.dll+0xf66ba 20 xul.dll+0x4e5173 21 xul.dll+0x4e5136 22 xul.dll+0x4e4e1c 23 xul.dll+0x4e4adc 24 xul.dll+0x4e4a87 25 xul.dll+0x5ebe3b 26 xul.dll+0x644fbc 27 xul.dll+0x7ced39 28 firefox.exe+0x2a36 29 firefox.exe+0x1180 30 firefox.exe!GetHandleVerifier+0x2a3d 31 kernel32.dll!BaseThreadInitThunk+0xd 32 ntdll.dll!RtlUserThreadStart+0x21 Does this help? What am I looking for?
(In reply to Dr B W Darvell from comment #126) ... > 25 xul.dll+0x4e4adc This is still not using the correct symbols, that 0x4e4adc would be resolved to a function something like xul.dll!MessageLoop::RunHandler+0x20 I was forgetting that I think you also need a full version of dbghelp.dll configured in the same dialog, you would need to install some development tools to get that. For example: https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk I think you only need to install the debugging tools and then look for dbghelp.dll. > Does this help? To be honest, trying to catch the problem by looking at stacks in Process Explorer is probably not the best approach, although it can sometimes help. The best way is probably by trying to get the profile data mconley was talking about, this will give a broader set of data, which means we're more likely to be able to spot the problem (or problems).
C:\Windows\system32\dbghelp.dll is rferenced in the PE Configure Symbols - wrong version? I'll check later. I will wait for another lockup and see if I can capture what is needed. As I said, I do not have the time to go through a nightly installation, with the risks involved in all that.
C:\Windows\system32\dbghelp.dll is rferenced in the PE Configure Symbols - wrong version? I'll check later. I will wait for another lockup and see if I can capture what is needed. As I said, I do not have the time to go through a nightly installation, with the risks involved in all that.
- perhaps a reboot is required for symbols to be used? This machine is on for long periods.
(In reply to Dr B W Darvell from comment #128) > C:\Windows\system32\dbghelp.dll is rferenced in the PE Configure Symbols - > wrong version? I'll check later. This is not a full version unfortunately, I think you need one from development tools. You shouldn't need to reboot.
OK, installed ... GHV has disappeared from the Threads list, I have to suppose that it is renamed as well: firefox.exe|wmainCRTStartup - since this is taking most CPU. Is that true? The stack for this looks like this: ntoskrnl.exe!memset+0x64a ntoskrnl.exe!KeWaitForMultipleObjects+0xd52 ntoskrnl.exe!KeWaitForMutexObject+0x19f ntoskrnl.exe!_misaligned_access+0xbd4 ntoskrnl.exe!_misaligned_access+0x186d ntoskrnl.exe!IoFreeErrorLogEntry+0x287 xul.dll!nsIDocument::GetInnerWindow+0x7 xul.dll!MarkContentViewer+0x58 xul.dll!MarkDocShell+0x67 xul.dll!MarkDocShell+0x17e xul.dll!MarkWindowList+0x84 xul.dll!nsCCUncollectableMarker::Observe+0xd8 xul.dll!nsObserverList::NotifyObservers+0x62 xul.dll!nsObserverService::NotifyObservers+0xf5 xul.dll!XPCJSContext::PrepareForForgetSkippable+0x31 xul.dll!nsCycleCollector::ForgetSkippable+0x61 xul.dll!FireForgetSkippable+0x6a xul.dll!CCTimerFired+0x83 xul.dll!nsTimerImpl::Fire+0x307 xul.dll!nsTimerEvent::Run+0xf3 xul.dll!nsThread::ProcessNextEvent+0x26b xul.dll!mozilla::ipc::MessagePump::Run+0x9e xul.dll!MessageLoop::RunHandler+0x1b xul.dll!MessageLoop::Run+0x3e xul.dll!nsBaseAppShell::Run+0x3c xul.dll!nsAppShell::Run+0x2c xul.dll!nsAppStartup::Run+0x27 xul.dll!XREMain::XRE_mainRun+0x62b xul.dll!XREMain::XRE_main+0x2e4 xul.dll!XRE_main+0x55 firefox.exe!NS_internal_main+0x676 firefox.exe!wmain+0x140 firefox.exe!__scrt_common_main_seh+0x11d kernel32.dll!BaseThreadInitThunk+0xd ntdll.dll!RtlUserThreadStart+0x21 - does that make sense? Is it usable info?
(In reply to Dr B W Darvell from comment #132) > OK, installed ... > GHV has disappeared from the Threads list, I have to suppose that it is > renamed as well: firefox.exe|wmainCRTStartup - since this is taking most > CPU. Is that true? Yes that is the correct start address now and it appears the symbols are being picked up correctly. Looks like it is doing some sort of garbage collection, but that is just a point in time, so it's possible that isn't what is taking all the CPU time. mconley might have more idea about this as I know he's been looking at performance issues.
Flags: needinfo?(mconley)
OK, good. Thanks. Are line such as ntoskrnl.exe!_misaligned_access+0xbd4 a problem? To my eye it suggests an error. [Off now for a few hours.]
I have a stack trace from windbg of the thread that is continuously spinning, and presumably that causes my hang. Seems to be doing something with regular expressions. I assume that this is the UI thread xul!js::irregexp::InterpretCode<unsigned char>+0x139 [c:\builds\moz2_slave\m-rel-w64-00000000000000000000\build\src\js\src\irregexp\regexpinterpreter.cpp @ 271] xul!js::RegExpShared::execute+0x2f1 [c:\builds\moz2_slave\m-rel-w64-00000000000000000000\build\src\js\src\vm\regexpobject.cpp @ 1176] xul!ExecuteRegExpImpl+0x27 [c:\builds\moz2_slave\m-rel-w64-00000000000000000000\build\src\js\src\builtin\regexp.cpp @ 127] xul!ExecuteRegExp+0x21d [c:\builds\moz2_slave\m-rel-w64-00000000000000000000\build\src\js\src\builtin\regexp.cpp @ 971] xul!js::RegExpTesterRaw+0x23 [c:\builds\moz2_slave\m-rel-w64-00000000000000000000\build\src\js\src\builtin\regexp.cpp @ 1199] 0x0000021a`9d7776bc 0xf962f5b0 0x0000004f`00000000 0x0000021a`00000000 0x2844 0x0000004f`767f86e4 0x0000004f`767f86e4 The only modules I don't have symbols for are the following: <Unloaded> 00007ff8`bc200000 00007ff8`bc205000 Sat Jul 16 03:28:55 2016 (57899be7) 0000659a None KBDUK.DLL <Unloaded> 00007ff8`bd380000 00007ff8`bd39b000 Sat Jul 16 03:26:29 2016 (57899b55) 0001dff8 None resourcepolicyclient.dll <Unloaded> 00007ff8`bc210000 00007ff8`bc238000 Wed Nov 04 21:16:19 2015 (563a75a3) 00035e64 None C:\WINDOWS\SYSTEM32\atiuxp64.dll
We seem to be going in circles a bit - because if you're finding that you're GC'ing a lot, then the next thing I'm going to ask for is an about:memory report, but I see you've been posting those for a while now. Perhaps we've got a new leak here? When you in this state again, are you able to produce yet another about:memory report and post it in this bug?
Flags: needinfo?(mconley) → needinfo?(hrdubwd)
Attached file memory-report.json.gz (obsolete) —
For reference - no problem at this point.
I can do that, of course. An assumed no-problem report just uploaded, in case comparison helps. On the other had, if something shows now ...
Capture during a slow response period, albeit fairly short, just in case there is something of interest.
Attachment #8710630 - Attachment is obsolete: true
Attachment #8842085 - Attachment is obsolete: true
Attachment #8842990 - Attachment is obsolete: true
Attachment #8843688 - Attachment is obsolete: true
Attachment #8846333 - Attachment is obsolete: true
Attachment #8873564 - Attachment is obsolete: true
Flags: needinfo?(hrdubwd)
And one a minute or so later.
... and again.
Another period of high CPU.
Unfortunately, these profiles are of limited value because they're not being captured on Nightly. From them, however, I can confirm that we're still spending a lot of time sweeping / GC'ing. An about:memory report rather than a profile when you're in this state might be better.
OK, I'll try to do that. re: Nightly - what are the risks, where do I get it, and how would I return to the main release version - seamlessly? Does it mean I have to do a fresh install every day? * Can you verify that GetHandleVerifier is now renamed firefox.exe|wmainCRTStartup because of the symbol loading? * Can you say what that routine is supposed to be doing and why it takes so much CPU continuously? * Could you comment on what this means: ntoskrnl.exe!_misaligned_access ? (This is always present, twice.) * I have just found this in the stack for GHV: xul.dll!js::detail::HashTable<js::HashMapEntry<js::CrossCompartmentKey,js::detail::UnsafeBareReadBarriered<JS::Value> >,js::HashMap<js::CrossCompartmentKey,js::detail::UnsafeBareReadBarriered<JS::Value>,js::CrossCompartmentKey::Hasher,js::SystemAllocPolic - which looks like another error. True? Thanks.
Flags: needinfo?(mconley)
(In reply to Dr B W Darvell from comment #144) > OK, I'll try to do that. > > re: Nightly - what are the risks, where do I get it, and how would I return > to the main release version - seamlessly? Does it mean I have to do a fresh > install every day? Yes, there are some risks. There are times when changes land in Nightly where it becomes hard to migrate _back_ to an earlier version. Most recently, bug 977177 introduced such a change. In times like this, it is sometimes more convenient to _clone_ your user profile, and use one in Nightly, and the other in Release. Here is a document regarding backing up / restoring your user profile that might help: https://support.mozilla.org/en-US/kb/back-and-restore-information-firefox-profiles Nightly can be downloaded and installed from https://www.mozilla.org/en-US/firefox/channel/desktop/#nightly As a browser, it's really quite stable. Tens of thousands (including myself) use it as our everyday browser. > * Can you verify that GetHandleVerifier is now renamed > firefox.exe|wmainCRTStartup because of the symbol loading? > * Can you say what that routine is supposed to be doing and why it takes so > much CPU continuously? > * Could you comment on what this means: ntoskrnl.exe!_misaligned_access ? > (This is always present, twice.) > * I have just found this in the stack for GHV: > xul.dll!js::detail::HashTable<js::HashMapEntry<js::CrossCompartmentKey,js:: > detail::UnsafeBareReadBarriered<JS::Value> > >,js::HashMap<js::CrossCompartmentKey,js::detail::UnsafeBareReadBarriered<JS: > :Value>,js::CrossCompartmentKey::Hasher,js::SystemAllocPolic > - which looks like another error. True? I'm afraid I don't know enough about this level of Firefox or Gecko to say with any certainty - redirecting needinfo to bobowen.
Flags: needinfo?(mconley) → needinfo?(bobowencode)
(In reply to Dr B W Darvell from comment #144) ... > * Can you verify that GetHandleVerifier is now renamed > firefox.exe|wmainCRTStartup because of the symbol loading? Yes, that is the same thread ... the main thread. The GetHandleVerifier start address was due to incorrect symbol resolution by Process Explorer the wmainCRTStartup address is correct. > * Can you say what that routine is supposed to be doing and why it takes so > much CPU continuously? It isn't, it is the starting function for that thread, not what it is doing at the point you are experiencing an issue. Lots of things process on the main thread, tracking down which thing (or things) is causing this issue is what mconley is trying to do with the profiles he is requesting. > * Could you comment on what this means: ntoskrnl.exe!_misaligned_access ? > (This is always present, twice.) I believe it is something to do with the kernel re-aligning variables for other APIs that require it, although I'm not at all sure. I really don't know if that could be the cause of your issues, but either way we would need to find the parts of our code that are causing this (if it is the underlying cause). That brings us back to getting profiles. > * I have just found this in the stack for GHV: > xul.dll!js::detail::HashTable<js::HashMapEntry<js::CrossCompartmentKey,js:: > detail::UnsafeBareReadBarriered<JS::Value> > >,js::HashMap<js::CrossCompartmentKey,js::detail::UnsafeBareReadBarriered<JS: > :Value>,js::CrossCompartmentKey::Hasher,js::SystemAllocPolic > - which looks like another error. True? This is just code within the JS engine. I don't know too much about that, but if you are referring to the "Unsafe" part of the function name, I don't think that indicates an error.
Flags: needinfo?(bobowencode)
(in reply to #145) OK, thanks - will try to find time to get that organized. (in reply to #146) And also thanks - all noted. The GHV part now makes much more sense! I still find it odd that it is running so much when everything is (supposedly) quiescent, but no matter. One day I might try a stripped-out run ...
I also had this problem and investigated a little bit.. I killed FF then restarted, restored crashed session, provided master password, same behaviour... saved a first report. Then I closed firefox, started it back again, it had a couple hiccups and it worked nicely... saved a second report. then I thought I should click the tabs in the background, at least to have the same active tabs and boom, it`s back again... it seems visiting the page http://www.munchkin.com/latchtm-transition-cup.html (no advertising here) caused this behavior. I have also visited FB, this page and some google searched (closed already) + care.com page -- see it in report. I have some company-server support pages but they were simply "ghost" tabs (don`t know how to call them... they were restored, I did not clicked them to have ff reload the page). so, here I create a 3rd report (this time I am authenticated in bugzilla). I`ll also add some screenshots, maybe they are of help for anyone... otherwise someone please erase them.
Well surprise.. closing the munchkin webpage solved the issue... can`t believe it.. I`ll create a 4th report.
Having updated to 54.0.1 I was hoping to see a dramatic chnage in behaviour, but while activity is spread over 8 cores, and the background CPU use seems lower than it used to be, I do not have the multiprocess window - apparently due to add-ons interfering. How do I tell which ones are the problem? Do I have to go through the the whole lot systematically again? Thanks.
Restarting with add-ons disabled I still get: Multiprocess Windows 0/1 (Disabled by add-ons) The only ones enabled are the hidden ones: Application Update Service Helper 2.0 true aushelper@mozilla.org Firefox Screenshots 6.6.0 true screenshots@mozilla.org Multi-process staged rollout 1.50 true e10srollout@mozilla.org Pocket 1.0.5 true firefox@getpocket.com Web Compat 1.1 true webcompat@mozilla.org So why can I not see multiprocess enabled? I had set dom.ipc.processCount to 2, but even that seems to have been ignored. What am I missing?
Looking further (about:config|e10s), I find this: elOs.rollout.cohort user set string disqualified-test elOs.rollout.cohortSample user set string 0.458686 extensions.bootstrappedAddons user set string {"spdyindicator@cheng•... extensions.elOs.rollout.blocklist user set string extensions.elOs.rollout.hasAddon user set boolean false extensions.elOs.rollout.policy user set string 50allmpc extensions.elOsBlockedByAddons user set boolean true extensions.elOsBlocksEnabling default boolean true extensions.elOsMuftiBlockedByAddons user set boolean true extensions.elOsMultiBlocksEnabling default boolean true extensions .. elOsrollout@mozilla.org.install-event-fired user set boolean true - which suggests to my untrained eye that I was not supposed to have multi-. True? When will this happen, then?
Ah: https://hacks.mozilla.org/2017/06/firefox-54-e10s-webextension-apis-css-clip-path/#comment-21286 "Currently, e10s-multi is only turned on by default for users without any add-ons installed." I shall have to wait, I suppose.
Like yourself, I had the same persistent issues in Firefox 32-bit on Windows 7 Pro x64, for about the last 3 months. In the end, the fix was to update to 64-bit Firefox, and replace FireGestures with Mouse Gesture Events. No other changes to my profile were necessary. I'm currently using ESR 52.7.3 with over 20 add-ons, and E10S-multi is not enabled. There are no more daily crashes after 6-8 hours and ~2.1 to ~2.2 GB of RAM usage, which was typical under the 32-bit edition. Now RAM usage by Firefox goes as high as 2.6 GB for me, typically, in a 9 hour session. I restart my PC daily at the end of my work shift. Application Basics ------------------ Name: Firefox Version: 52.7.3 Build ID: 20180322140748 Update Channel: esr User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0 OS: Windows_NT 6.1 Multiprocess Windows: 0/12 (Disabled by add-ons) Safe Mode: false Crash Reports for the Last 3 Days --------------------------------- All Crash Reports Extensions ---------- Name: Add to Bookmark Ninja Version: 1.0.0.2 Enabled: true ID: {f5e8db67-96ed-47fb-a39f-534e1d56aadf} Name: Application Update Service Helper Version: 2.0 Enabled: true ID: aushelper@mozilla.org Name: Bookmark Dupes Version: 5.7 Enabled: true ID: bookmarkdupes@martin-vaeth.org Name: Bookmark Ninja Version: 1.0.0.1 Enabled: true ID: {47e7fc3c-b553-4aa7-bf22-9bdaa4339301} Name: CanvasBlocker Version: 0.4.4b Enabled: true ID: CanvasBlocker@kkapsner.de Name: Classic Reload-Stop-Go Button Version: 1.1 Enabled: true ID: crsg@ArisT2_Noia4dev Name: Cookie Controller Version: 6.1 Enabled: true ID: {ac2cfa60-bc96-11e0-962b-0800200c9a66} Name: Copy Urls Expert Version: 2.6.1 Enabled: true ID: copy-urls-expert@kashiif-gmail.com Name: DownThemAll! Version: 3.0.8 Enabled: true ID: {DDC359D1-844A-42a7-9AA1-88A850A938A8} Name: Font Finder Version: 0.1.8 Enabled: true ID: {a658a273-612e-489e-b4f1-5344e672f4f5} Name: Google search link fix Version: 1.6.7 Enabled: true ID: jid0-XWJxt5VvCXkKzQK99PhZqAn7Xbg@jetpack Name: Informational Tab Version: 0.5.2017061501 Enabled: true ID: informationaltab@piro.sakura.ne.jp Name: Mouse Gesture Events Version: 2.3 Enabled: true ID: @mousegesture Name: Multi-process staged rollout Version: 1.10 Enabled: true ID: e10srollout@mozilla.org Name: Personas Plus Version: 2.0.1 Enabled: true ID: personas@christopher.beard Name: Pocket Version: 1.0.5 Enabled: true ID: firefox@getpocket.com Name: PriceBlink Coupons and Price Comparison Version: 6.6 Enabled: true ID: info@priceblink.com Name: Reload Plus Version: 5.2.3 Enabled: true ID: reloadplus@blackwind Name: Restart Version: 3.0.2 Enabled: true ID: Restart@schuzak.jp Name: Secure Login (Embedded WebExtension) Version: 0.2.1 Enabled: true ID: @slogin Name: Tampermonkey Version: 4.6.5757 Enabled: true ID: firefox@tampermonkey.net Name: Tree Style Tab Version: 0.19.2017090601 Enabled: true ID: treestyletab@piro.sakura.ne.jp Name: uBlock Origin Version: 1.16.2 Enabled: true ID: uBlock0@raymondhill.net Name: UnMHT Version: 8.3.2 Enabled: true ID: {f759ca51-3a91-4dd1-ae78-9db5eee9ebf0} Name: Web Compat Version: 1.0 Enabled: true ID: webcompat@mozilla.org Name: DuckDuckGo Plus Version: 2017.11.15 Enabled: false ID: jid1-ZAdIEUB7XOzOJw@jetpack Name: User Agent Switcher Version: 0.7.3.1-signed.1-signed Enabled: false ID: {e968fc70-8f95-4ab9-9e79-304de2a71ee1} Graphics -------- Features Compositing: Direct3D 11 Asynchronous Pan/Zoom: none WebGL Renderer: Google Inc. -- ANGLE (Intel(R) HD Graphics Direct3D11 vs_5_0 ps_5_0) WebGL2 Renderer: Google Inc. -- ANGLE (Intel(R) HD Graphics Direct3D11 vs_5_0 ps_5_0) Hardware H264 Decoding: Yes; Using D3D9 API Audio Backend: wasapi Direct2D: true DirectWrite: true (6.2.9200.22164) GPU #1 Active: Yes Description: Intel(R) HD Graphics Vendor ID: 0x8086 Device ID: 0x0152 Driver Version: 9.17.10.3040 Driver Date: 2-22-2013 Drivers: igdumd64 igd10umd64 igd10umd64 igdumd32 igd10umd32 igd10umd32 Subsys ID: 05771028 RAM: Unknown GPU #2 Active: No Description: AMD Radeon HD 7470 Vendor ID: 0x1002 Device ID: 0x6778 Driver Version: 8.922.0.0 Driver Date: 12-6-2011 Drivers: atiu9p64 atiuxp64 atiuxp64 atiu9pag atiuxpag atiuxpag atiumdva atiumd6a atitmm64 Subsys ID: 21201028 RAM: 1024 Diagnostics ClearType Parameters: DISPLAY1 [ Gamma: 2.2 Pixel Structure: BGR ClearType Level: 50 Enhanced Contrast: 50 ] DISPLAY2 [ Gamma: 2.2 Pixel Structure: RGB ClearType Level: 0 Enhanced Contrast: 50 ] DISPLAY4 [ Gamma: 2.2 Pixel Structure: BGR ClearType Level: 0 Enhanced Contrast: 100 ] AzureCanvasAccelerated: 0 AzureCanvasBackend: direct2d 1.1 AzureContentBackend: direct2d 1.1 AzureFallbackCanvasBackend: cairo ClearType Parameters: DISPLAY1 [ Gamma: 2.2 Pixel Structure: BGR ClearType Level: 50 Enhanced Contrast: 50 ] DISPLAY2 [ Gamma: 2.2 Pixel Structure: RGB ClearType Level: 0 Enhanced Contrast: 50 ] DISPLAY4 [ Gamma: 2.2 Pixel Structure: BGR ClearType Level: 0 Enhanced Contrast: 100 ] Decision Log D3D9_COMPOSITING: disabled by default: Disabled by default Important Modified Preferences ------------------------------ accessibility.typeaheadfind.flashBar: 0 browser.cache.disk.capacity: 358400 browser.cache.disk.filesystem_reported: 1 browser.cache.disk.hashstats_reported: 1 browser.cache.disk.smart_size.enabled: false browser.cache.disk.smart_size.first_run: false browser.cache.disk.smart_size.use_old_max: false browser.cache.frecency_experiment: 4 browser.download.importedFromSqlite: true browser.download.useDownloadDir: false browser.places.smartBookmarksVersion: 8 browser.sessionstore.restore_on_demand: false browser.sessionstore.upgradeBackup.latestBuildID: 20180322140748 browser.startup.homepage: https://start.duckduckgo.com browser.startup.homepage_override.buildID: 20180322140748 browser.startup.homepage_override.mstone: 52.7.3 browser.tabs.remote.autostart.2: true browser.urlbar.daysBeforeHidingSuggestionsPrompt: 0 browser.urlbar.lastSuggestionsPromptDate: 20171122 browser.urlbar.maxRichResults: 20 browser.urlbar.suggest.history: false dom.ipc.processCount: 4 dom.push.userAgentID: <SCRUBBED> extensions.lastAppVersion: 52.7.3 font.name.serif.x-western: Calibri font.size.fixed.x-western: 12 general.autoScroll: false gfx.color_management.mode: 1 gfx.crash-guard.d3d11layers.appVersion: 52.7.3 gfx.crash-guard.d3d11layers.deviceID: 0x0152 gfx.crash-guard.d3d11layers.driverVersion: 9.17.10.3040 gfx.crash-guard.d3d11layers.feature-d2d: true gfx.crash-guard.d3d11layers.feature-d3d11: true gfx.crash-guard.status.d3d11layers: 2 gfx.crash-guard.status.d3d9video: 2 gfx.font_rendering.cleartype.always_use_for_content: true media.benchmark.vp9.fps: 193 media.benchmark.vp9.versioncheck: 1 media.gmp-gmpopenh264.abi: x86_64-msvc-x64 media.gmp-gmpopenh264.lastUpdate: 1523364906 media.gmp-gmpopenh264.version: 1.6 media.gmp-manager.buildID: 20180322140748 media.gmp-manager.lastCheck: 1524747216 media.gmp-widevinecdm.abi: x86_64-msvc-x64 media.gmp-widevinecdm.lastUpdate: 1523364907 media.gmp-widevinecdm.version: 1.4.8.903 media.gmp.storage.version.observed: 1 media.hardware-video-decoding.failed: false media.webrtc.debug.log_file: <SCRUBBED>\AppData\Local\Temp\WebRTC.log network.cookie.cookieBehavior: 3 network.cookie.lifetimePolicy: 2 network.cookie.prefsMigrated: true network.predictor.cleaned-up: true places.database.lastMaintenance: 1524151136 places.history.expiration.transient_current_max_pages: 71962 plugin.disable_full_page_plugin_for_types: application/pdf plugin.state.flash: 1 plugin.state.npadobeaamdetect: 2 plugin.state.npadobeexmandetectx: 2 plugin.state.npdeployjava: 0 plugin.state.npgoogletalk: 2 plugin.state.npo1d: 2 plugin.state.nppdf: 0 print.printer_CutePDF_Writer.print_bgcolor: true print.printer_CutePDF_Writer.print_bgimages: true print.printer_CutePDF_Writer.print_duplex: -437918235 print.printer_CutePDF_Writer.print_edge_bottom: 0 print.printer_CutePDF_Writer.print_edge_left: 0 print.printer_CutePDF_Writer.print_edge_right: 0 print.printer_CutePDF_Writer.print_edge_top: 0 print.printer_CutePDF_Writer.print_evenpages: true print.printer_CutePDF_Writer.print_footercenter: print.printer_CutePDF_Writer.print_footerleft: &PT print.printer_CutePDF_Writer.print_footerright: &D print.printer_CutePDF_Writer.print_headercenter: print.printer_CutePDF_Writer.print_headerleft: &T print.printer_CutePDF_Writer.print_headerright: &U print.printer_CutePDF_Writer.print_in_color: true print.printer_CutePDF_Writer.print_margin_bottom: 0 print.printer_CutePDF_Writer.print_margin_left: 0 print.printer_CutePDF_Writer.print_margin_right: 0 print.printer_CutePDF_Writer.print_margin_top: 0 print.printer_CutePDF_Writer.print_oddpages: true print.printer_CutePDF_Writer.print_orientation: 0 print.printer_CutePDF_Writer.print_page_delay: 50 print.printer_CutePDF_Writer.print_paper_data: 1 print.printer_CutePDF_Writer.print_paper_height: -1.00 print.printer_CutePDF_Writer.print_paper_name: print.printer_CutePDF_Writer.print_paper_size_unit: 0 print.printer_CutePDF_Writer.print_paper_width: -1.00 print.printer_CutePDF_Writer.print_resolution: 600 print.printer_CutePDF_Writer.print_reversed: false print.printer_CutePDF_Writer.print_scaling: 0.70 print.printer_CutePDF_Writer.print_shrink_to_fit: true print.printer_CutePDF_Writer.print_to_file: false print.printer_CutePDF_Writer.print_unwriteable_margin_bottom: 0 print.printer_CutePDF_Writer.print_unwriteable_margin_left: 0 print.printer_CutePDF_Writer.print_unwriteable_margin_right: 0 print.printer_CutePDF_Writer.print_unwriteable_margin_top: 0 privacy.clearOnShutdown.cache: false privacy.clearOnShutdown.cookies: false privacy.clearOnShutdown.downloads: false privacy.clearOnShutdown.history: false privacy.cpd.cookies: false privacy.cpd.downloads: false privacy.cpd.formdata: false privacy.cpd.history: false privacy.cpd.offlineApps: true privacy.donottrackheader.enabled: true privacy.sanitize.sanitizeOnShutdown: true privacy.sanitize.timeSpan: 0 security.sandbox.content.tempDirSuffix: {2116e583-0c18-4d52-b9f4-ac5823e01f15} services.sync.declinedEngines: forms,history,tabs services.sync.engine.history: false services.sync.engine.prefs.modified: false services.sync.engine.tabs: false services.sync.lastPing: 1524747757 services.sync.lastSync: Thu Apr 26 2018 12:02:14 GMT-0500 (Central Standard Time) services.sync.numClients: 3 storage.vacuum.last.index: 1 storage.vacuum.last.places.sqlite: 1524245127 storage.vacuum.last.queue.sqlite: 1522164427 user.js Preferences ------------------- Your profile folder contains a user.js file, which includes preferences that were not created by Firefox. Important Locked Preferences ---------------------------- Places Database --------------- JavaScript ---------- Incremental GC: true Accessibility ------------- Activated: false Prevent Accessibility: 0 Library Versions ---------------- NSPR Expected minimum version: 4.13.1 Version in use: 4.13.1 NSS Expected minimum version: 3.28.6 Version in use: 3.28.6 NSSSMIME Expected minimum version: 3.28.6 Version in use: 3.28.6 NSSSSL Expected minimum version: 3.28.6 Version in use: 3.28.6 NSSUTIL Expected minimum version: 3.28.6 Version in use: 3.28.6 Experimental Features --------------------- Sandbox ------- Content Process Sandbox Level: 1 (In reply to Dr B W Darvell from comment #0) > User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 > Firefox/43.0 > Build ID: 20160105164030 > > Steps to reproduce: > > I have 18 tabs pinned for very frequently used pages, and then may open > anything from a few to many tabs in the course of my work (academic stuff). > FF works well most of the time, but occasionally, but with monotonous > regularity, it will go dead slow, consuming up to ~36% CPU, and so making FF > use difficult to say the least, but also slowing the machine appreciably. I > have let it run in this state for hours, and it never resolves. For > comparison, the normal background tickover is around 2 or 3%, with > occasional extra activity to say 10%. No problem with this at all. > > What seems to be happening is that memory is being shuffled around, or the > contents thereof. The fact is that there is some 20 GB of free RAM, of > which about 2 GB is being used (the numbers tick up and down continuously > during this kind of event). I have put the cache into RAM on a virtual > drive, along with all Windows temp files, so that should not be a problem - > there is plenty of memory there as well, 20 GB!, no indexing, no > compression. (After crashing and restarting to write this up, memory usage > is around 1.3 GB, CPU usage around 2 - 5% - no problem to use.) > > This is under W7 Pro, 64-bit. It has been occurring for all of at least a > few of the previous versions of FF. > > The only way to deal with it is to crash FF and reload, when after the > loading settling down, all is well again, until some random point in the > future. This has now happened many times. I have held off reporting > thinking that I might identify the problem with a specific tab. I cannot.) > > I cannot see any similar reports of this kind of behaviour, except for some > very specific single-tab problems, for example. > > > Actual results: > > Excessive CPU usage slows FF to a crawl, and interferes with the machine > generally, by causing slow responses. > > > Expected results: > > Memory clean-up from time to time would not be a problem, but locked in a > seemingly unending cycle is not functional.
Just to update, I have not encountered any problems for quite some time now. e10s seems to work well (8 cores all busy), I have not suffered any FF-related slowdowns, that I have noticed, at any rate. My cache is now mostly in memory (and as RAMdisk as well). The only limitation now seems to be the (lack of) responsiveness of remote servers. I have many tabs open. I had forgotten about this as the problems faded. I suppose this bug can be closed as resolved, although the resolution was just part of the (extra!)ordinary development of FF - for which I am grateful (thanks all ... ). Perhaps the disabling of incompatible add-ons played a part. BWD
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: