User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0 Build ID: 20141024080301 Steps to reproduce: Assuming E10S is enabled 1 - Open this PDF link http://arxiv.org/pdf/1410.6192v1 2 - Navigate through the document and then close it Actual results: While a 103 pages pdf file can really cause a significant memory usage closing it won't solve the issue Expected results: Firefox must open every newly opened PDF file in a new plugin-container so that the memory associated with it will be fully recovered whenever that child-process/tab is closed

I just tried this document on Linux. Memory usage was very reasonable -- RSS didn't exceed 300 MiB scrolling through the PDF -- and the tab's memory was reclaimed as expected when I closed the tab. Achwaq, when you see the high memory usage, could you please open a new tab, type "about:memory" in the address bar, click on the "Measure..." button, and then upload the resulting file to this bug? That will give us better information. Please note that if you do this all the tabs you have open will be visible; if that's a problem you can click on the "anonymize" check box before hitting "Measure...". Thank you.

Achwaq, does that summary capture the problem? If so, do you have any addons installed? Also, have you changed the number of processes? More than one content process isn't well supported yet.

(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #2) > Achwaq, does that summary capture the problem? If so, do you have any addons > installed? Also, have you changed the number of processes? More than one > content process isn't well supported yet. The problem is not that PDF.js uses a huge amount of memory but from an architectural point of view and for the sake of performance and stability it will be better that firefox fires a new container for every newly opened PDF document, I already discussed this with Mike in twitter (https://twitter.com/mike_conley/status/515199655747923968) and I just want to file a bug for it to keep things in track, this being said I don't think that the summary name save the initial purpose now!

(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #2) > Achwaq, does that summary capture the problem? If so, do you have any addons > installed? Also, have you changed the number of processes? More than one > content process isn't well supported yet. Oh yeah and as of the number of processes i'm still sticking with ProcessCount=1 otherwise a sample pop-up will crash my tabs :) Application Basics ------------------ Name: Firefox Version: 36.0a1 User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0 Multiprocess Windows: 1/1 Crash Reports for the Last 3 Days --------------------------------- Report ID: bp-de0b77a8-a652-4134-9a31-cae612141027 Submitted: 24 hours ago Report ID: bp-e6a5d18e-73b9-4122-860a-760922141027 Submitted: 1 day ago All Crash Reports (including 4 pending crashes in the given time range) Extensions ---------- Name: Adblock Plus Version: 2.6.5 Enabled: true ID: {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d} Name: Flagfox Version: 5.0.8 Enabled: true ID: {1018e4d6-728f-4b20-ad56-37578a4de76b} Name: OneTab Version: 1.9 Enabled: true ID: extension@one-tab.com Name: Open With Version: 5.6.3 Enabled: true ID: openwith@darktrojan.net Name: Quick Translator Version: 2.0a1 Enabled: true ID: {5C655500-E712-41e7-9349-CE462F844B19} Name: Restart Version: 1.2.3 Enabled: true ID: Restart@schuzak.jp Name: SearchPreview Version: 7.1 Enabled: true ID: {EF522540-89F5-46b9-B6FE-1829E2B572C6} Name: Session Manager Version: 0.8.1.6 Enabled: true ID: {1280606b-2510-4fe0-97ef-9b5a22eafe30} Name: Tab Counter Version: 1.9.9 Enabled: true ID: tabcounter@morac Name: Tab Scope Version: 1.5 Enabled: true ID: tabscope@xuldev.org Name: Turn Off the Lights Version: 3.0.0.16 Enabled: true ID: stefanvandamme@stefanvd.net Name: FastestFox Version: 5.2.1 Enabled: false ID: smarterwiki@wikiatic.com Name: IDM CC Version: 7.3.87 Enabled: false ID: mozilla_cc@internetdownloadmanager.com Name: Multi Links Version: 3.0.0.19 Enabled: false ID: multilinks@plugin Name: User Agent Overrider Version: 0.2.4 Enabled: false ID: useragentoverrider@qixinglu.com Name: WiseStamp Version: 3.13.44 Enabled: false ID: wisestamp@wisestamp.com Graphics -------- Adapter Description: NVIDIA GeForce 9700M GT Adapter Drivers: nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um Adapter RAM: 512 Device ID: 0x064a Direct2D Enabled: true DirectWrite Enabled: true (6.3.9600.17111) Driver Date: 7-2-2014 Driver Version: 9.18.13.4052 GPU #2 Active: false GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC) Subsys ID: 01451025 Vendor ID: 0x10de WebGL Renderer: Google Inc. -- ANGLE (NVIDIA GeForce 9700M GT Direct3D9Ex vs_3_0 ps_3_0) windowLayerManagerRemote: true AzureCanvasBackend: direct2d AzureContentBackend: direct2d 1.1 AzureFallbackCanvasBackend: cairo AzureSkiaAccelerated: 0 Important Modified Preferences ------------------------------ accessibility.browsewithcaret_shortcut.enabled: false accessibility.typeaheadfind.flashBar: 0 browser.cache.disk.capacity: 358400 browser.cache.disk.smart_size_cached_value: 71680 browser.cache.disk.smart_size.first_run: false browser.cache.disk.smart_size.use_old_max: false browser.cache.frecency_experiment: 1 browser.places.smartBookmarksVersion: 7 browser.sessionstore.max_tabs_undo: 20 browser.sessionstore.max_windows_undo: 10 browser.sessionstore.upgradeBackup.latestBuildID: 20141028030204 browser.startup.homepage: www.google.com browser.startup.homepage_override.buildID: 20141028030204 browser.startup.homepage_override.mstone: 36.0a1 browser.tabs.remote.autostart: true dom.ipc.plugins.reportCrashURL: false dom.max_script_run_time: 0 dom.mozApps.used: true dom.serviceWorkers.enabled: true extensions.lastAppVersion: 36.0a1 font.internaluseonly.changed: true font.size.variable.x-western: 20 gfx.direct3d.last_used_feature_level_idx: 1 gfx.font_rendering.directwrite.enabled: true gfx.layerscope.enabled: true layers.acceleration.force-enabled: true media.gmp-gmpopenh264.enabled: true media.gmp-gmpopenh264.lastUpdate: 1412184250 media.gmp-gmpopenh264.path: C:\Users\PC-Admin\AppData\Roaming\Mozilla\Firefox\Profiles\3azmrd7z.default\gmp-gmpopenh264 media.gmp-gmpopenh264.version: 1.1 media.gmp-manager.lastCheck: 1414520512 network.cookie.prefsMigrated: true places.database.lastMaintenance: 1414520502 places.history.expiration.transient_current_max_pages: 70499 plugin.disable_full_page_plugin_for_types: application/pdf plugin.importedState: true plugin.state.flash: 1 plugin.state.npctrl: 1 plugin.state.nppdfxcviewnpplugin: 2 plugin.state.npvlc: 1 privacy.cpd.cookies: false privacy.cpd.downloads: false privacy.cpd.extensions-sessionmanager: false privacy.cpd.formdata: false privacy.cpd.history: false privacy.cpd.sessions: false privacy.sanitize.migrateFx3Prefs: true privacy.sanitize.timeSpan: 0 storage.vacuum.last.index: 1 storage.vacuum.last.places.sqlite: 1412014709 Important Locked Preferences ---------------------------- JavaScript ---------- Incremental GC: true Accessibility ------------- Activated: false Prevent Accessibility: 0 Library Versions ---------------- NSPR Expected minimum version: 4.10.7 Version in use: 4.10.7 NSS Expected minimum version: 3.18 Basic ECC Beta Version in use: 3.18 Basic ECC Beta NSSSMIME Expected minimum version: 3.18 Basic ECC Beta Version in use: 3.18 Basic ECC Beta NSSSSL Expected minimum version: 3.18 Basic ECC Beta Version in use: 3.18 Basic ECC Beta NSSUTIL Expected minimum version: 3.18 Beta Version in use: 3.18 Beta Experimental Features --------------------- Name: Invisible test of the experiment branching system. ID: experiment-branch-test-nightly@experiments.mozilla.org Description: An experiment using branches just to test whether branches get saved correctly. Active: false End Date: 1409612858674 Homepage: Name: tile switcher ID: tile-switcher@experiments.mozilla.org Description: An add-on which switches the location of NewTab tiles. Active: false End Date: 1398520881403 Homepage:

> The problem is not that PDF.js uses a huge amount of memory but from an > architectural point of view and for the sake of performance and stability it > will be better that firefox fires a new container for every newly opened PDF > document Firefox's use of pdf.js means that PDFs aren't really any different from any other web content tabs -- it's just HTML and JavaScript doing the rendering. So this bug basically boils down to the question "what is the right number of web content processes?" That question has multiple possible answers, and there are advantages and disadvantages to each answer, but my understanding is that when e10s is enabled the initial answer will be "one" and it may be raised later, carefully. But I don't think this bug is the right place to discuss this question. Also, in its current form this bug is misleading, because pdf.js isn't using a lot of memory for this example PDF. Plus, we have a bug about pdf.js memory usage (bug 881974). So I think this bug should be closed. Sound reasonable?

Would it be reasonable to spawn a new process just for pdf.js when a pdf is opened and terminate it when the last pdf.js "window" is closed? In theory (since pdf.js usually does take a lot of memory) this would prevent heap fragmentation and also prevent 32-bit system from hitting address space limits.

(In reply to ferongr from comment #7) > Would it be reasonable to spawn a new process just for pdf.js when a pdf is > opened and terminate it when the last pdf.js "window" is closed? In theory > (since pdf.js usually does take a lot of memory) this would prevent heap > fragmentation and also prevent 32-bit system from hitting address space > limits. @Nicholas Nethercote this is somehow my main idea although In it's current state firefox won't create a new plugin-container unless it's stated in About:Config which requires restarting the browser! what i'm suggesting is to fire a new plugin-container for every newly opened PDF file and close it whenever it's tab is closed while ignoring the ProcessCount PDF documents with rich graphic content sometimes really stress the browser and in laptops this can turn into a struggle

(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #2) > Achwaq, does that summary capture the problem? If so, do you have any addons > installed? Also, have you changed the number of processes? More than one > content process isn't well supported yet. As stated by Nicholas Nethercote "in its current form this bug is misleading, because pdf.js isn't using a lot of memory for this example PDF. Plus, we have a bug about pdf.js memory usage (bug 881974)." I also don't think that the current name serves the purpose of this bug

I've updated the bug title to match (I hope) the descriptions in comment 4, comment 7 and comment 8. Again, I don't think pdf.js tabs are notable different from other tabs -- non-pdf.js tabs can easily stress the browser just as much or more -- but I've set the "tracking-e10s" flag so the e10s people can make that decision. Either way, this doesn't need the "MemShrink" tag any more.

The tendency seems to be to share subprocesses rather than multiply them, see bug 641685 (which, IIUC, is about NPAPI plugin-container processes, including Acrobat Reader tabs but not PDF.js tabs).

(In reply to Tony Mechelynck [:tonymec] from comment #11) > The tendency seems to be to share subprocesses rather than multiply them, > see bug 641685 (which, IIUC, is about NPAPI plugin-container processes, > including Acrobat Reader tabs but not PDF.js tabs). I think the original motivation there might have been more about NPAPI plugins not expecting to have multiple instances running concurrently within the same browser instance. Also, sandboxing changes the landscape here — content processes need to stop creating their own child processes directly (especially NPAPI, because plugins typically need unrestricted access to the system), and multiple content processes can limit the impact of a content process compromise.