Closed Bug 1260462 Opened 8 years ago Closed 7 years ago

Firefox fails to exit properly on system shutdown with e10s enabled

Categories

(Core :: DOM: Content Processes, defect, P2)

Product:
Core
Component:
DOM: Content Processes
Platform:
x86_64
Windows 8.1
Type:
defect

Tracking

()

Status:
RESOLVED INCOMPLETE
Tracking Flags:
Tracking Status
e10s + ---

People

(Reporter: dqeswn, Unassigned)

References

(
URL
)

Details

(Whiteboard: triaged)

Attachments

(3 files)

plugin-containerAppError.PNG
(deleted), image/png
Details
SM log July-07
(deleted), text/plain
Details
another log, the second session ended with a crashed content process on shutdown
(deleted), text/plain
Details 
When I shutdown windows while Firefox with e10s enabled is running I get windows' crash alert window for all of the content processes.
Which hangs the shutdown process. I also have to close all of the alerts to continue, which is even more annoying.
This happens on every shutdown.

This might be related to bug 1260461, which is with e10s disabled but I can't tell.
Blocks: e10s
tracking-e10s: --- → ?
(In reply to avada from comment #0)
> When I shutdown windows while Firefox with e10s enabled is running I get
> windows' crash alert window for all of the content processes.

"All of the content processes" implies that you're running with dom.ipc.processCount > 1. Do you see the same behaviour if you reset that pref down to 1?
Flags: needinfo?(dqeswn)
(In reply to Mike Conley (:mconley) - Needinfo me! from comment #1)
> (In reply to avada from comment #0)
>Do you see the same behaviour if you reset that
> pref down to 1?

Yes.
Flags: needinfo?(dqeswn)
Do you have crash reports for those shutdown crashes?
Flags: needinfo?(dqeswn)
I doubt it. I don't think it produces crash reports in this case. Or at least not reliably. I just tested twice with logout, for one content process. (At first I forgot to change the setting)
But my last report is from today 1:51.(a bunch of them actually)  Which should be when I switched of my computer for the night.

All of them are "throttled".
Flags: needinfo?(dqeswn)
(In reply to avada from comment #4)
> I doubt it. I don't think it produces crash reports in this case. Or at
> least not reliably. I just tested twice with logout, for one content
> process. (At first I forgot to change the setting)
> But my last report is from today 1:51.(a bunch of them actually)  Which
> should be when I switched of my computer for the night.
> 
> All of them are "throttled".

Okay, if you click on those crash reports, it should get them started processing. When they're done, can you paste a link to one of them here?
Flags: needinfo?(dqeswn)
(In reply to Mike Conley (:mconley) - Needinfo me! from comment #5)
> Okay, if you click on those crash reports, it should get them started
> processing. When they're done, can you paste a link to one of them here?

These should be the ones:

https://crash-stats.mozilla.com/report/index/557692cb-d3c7-4c05-a3dc-e6ff82160404
https://crash-stats.mozilla.com/report/index/a5598535-689b-47a5-9770-b059f2160404
https://crash-stats.mozilla.com/report/index/86e06c5c-69db-4702-89b0-ab0172160404
https://crash-stats.mozilla.com/report/index/ca61604b-627a-4bb0-aba6-7de352160404
https://crash-stats.mozilla.com/report/index/f681171d-c3cb-44b3-9fe2-da4bf2160404
https://crash-stats.mozilla.com/report/index/7f0a5217-7dd9-43a1-a960-cf7cc2160404
https://crash-stats.mozilla.com/report/index/25f7f0cc-e6d0-49f8-82c8-084792160404
https://crash-stats.mozilla.com/report/index/373954d6-cd5f-43a9-9dbb-98ce52160404

Although it's a tad confusing because apparently more got submitted than I clicked and the dates were overwrote for all of them.

All but one seem to have the same signature.
Flags: needinfo?(dqeswn)
(In reply to avada from comment #6)
> (In reply to Mike Conley (:mconley) - Needinfo me! from comment #5)
> > Okay, if you click on those crash reports, it should get them started
> > processing. When they're done, can you paste a link to one of them here?
> 
> These should be the ones:
> 
> https://crash-stats.mozilla.com/report/index/557692cb-d3c7-4c05-a3dc-
> e6ff82160404
> https://crash-stats.mozilla.com/report/index/a5598535-689b-47a5-9770-
> b059f2160404
> https://crash-stats.mozilla.com/report/index/86e06c5c-69db-4702-89b0-
> ab0172160404
> https://crash-stats.mozilla.com/report/index/ca61604b-627a-4bb0-aba6-
> 7de352160404
> https://crash-stats.mozilla.com/report/index/f681171d-c3cb-44b3-9fe2-
> da4bf2160404
> https://crash-stats.mozilla.com/report/index/7f0a5217-7dd9-43a1-a960-
> cf7cc2160404
> https://crash-stats.mozilla.com/report/index/25f7f0cc-e6d0-49f8-82c8-
> 084792160404
> https://crash-stats.mozilla.com/report/index/373954d6-cd5f-43a9-9dbb-
> 98ce52160404
> 
> Although it's a tad confusing because apparently more got submitted than I
> clicked and the dates were overwrote for all of them.
> 
> All but one seem to have the same signature.

This looks like the parent is intentionally killing the child here.

If you boost dom.ipc.tabs.shutdownTimeoutSecs from 5 to something larger, like 20, or 30, do the crashes go away?
Flags: needinfo?(dqeswn)
(In reply to Mike Conley (:mconley) - Needinfo me! from comment #7)
> 
> This looks like the parent is intentionally killing the child here.
> 
> If you boost dom.ipc.tabs.shutdownTimeoutSecs from 5 to something larger,
> like 20, or 30, do the crashes go away?

Hmmm... Those crashes might be irrelevant after all. A different bug, or a different aspect of this bug. Looking at session manager the session at 1:51 is not a crashed session. So apparently I closed firefox manually. So it suggests when I do so firefox makes crash reports silently. But when I don't exit manually I don't get crash reports, but windows notifies me of the processes crashing.
Flags: needinfo?(dqeswn)
I'll increase the value of that setting at see what happens.
Setting it to 30 doesn't seem to make much of a difference. The content processes crashed after a few seconds.
Hey avada, can you post your about:support?
Flags: needinfo?(dqeswn)
(No need to needinfo me all the time. I'm cc'd.)

Since I believe my main profile is useless for this, because all the stuff in it, I'm gonna post it from a test profile. I can reproduce the issue here too. Withe e10s on/off, with or without the Session Manager addon. It does behave a little differently though. I don't get the crashed content processes, only the crashed session at startup. I also changed the title, since the crashing content processes are not consistent.

about:support:
{
  "application": {
    "name": "Firefox",
    "osVersion": "Windows_NT 6.3",
    "arch": "x86",
    "version": "48.0a1",
    "buildID": "20160405030214",
    "userAgent": "Mozilla/5.0 (Windows NT 6.3; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0",
    "safeMode": false,
    "updateChannel": "nightly",
    "supportURL": "https://support.mozilla.org/1/firefox/48.0a1/WINNT/hu/",
    "numTotalWindows": 1,
    "numRemoteWindows": 1,
    "remoteAutoStart": true,
    "autoStartStatus": 0
  },
  "modifiedPreferences": {
    "accessibility.typeaheadfind.flashBar": 0,
    "browser.cache.frecency_experiment": 3,
    "browser.cache.disk.smart_size.first_run": false,
    "browser.cache.disk.smart_size.use_old_max": false,
    "browser.cache.disk.capacity": 358400,
    "browser.cache.disk.filesystem_reported": 1,
    "browser.download.importedFromSqlite": true,
    "browser.places.smartBookmarksVersion": 7,
    "browser.sessionstore.upgradeBackup.latestBuildID": "20160405030214",
    "browser.sessionstore.resume_from_crash": false,
    "browser.startup.homepage_override.buildID": "20160405030214",
    "browser.startup.homepage_override.mstone": "48.0a1",
    "browser.tabs.remote.force-enable": true,
    "browser.tabs.remote.autostart.2": false,
    "browser.tabs.drawInTitlebar": false,
    "browser.urlbar.maxRichResults": 150,
    "browser.urlbar.userMadeSearchSuggestionsChoice": true,
    "dom.apps.reset-permissions": true,
    "dom.ipc.processCount": 33,
    "dom.mozApps.used": true,
    "extensions.lastAppVersion": "48.0a1",
    "gfx.crash-guard.d3d11layers.appVersion": "47.0a2",
    "gfx.crash-guard.d3d11layers.driverVersion": "10.18.13.6175",
    "gfx.driver-init.feature-d3d11": 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.direct3d11-angle": true,
    "gfx.driver-init.deviceID": "0x1245",
    "gfx.driver-init.driverVersion": "10.18.13.5598",
    "gfx.driver-init.status": 2,
    "gfx.crash-guard.glcontext.gfx.driver-init.webgl-angle": true,
    "gfx.crash-guard.glcontext.gfx.driver-init.webgl-angle-try-d3d11": true,
    "gfx.direct3d.last_used_feature_level_idx": 0,
    "gfx.crash-guard.d3d11layers.feature-d3d11": true,
    "gfx.driver-init.appVersion": "41.0.1",
    "gfx.crash-guard.d3d11layers.feature-d2d": true,
    "gfx.crash-guard.status.glcontext": 2,
    "gfx.crash-guard.d3d11layers.deviceID": "0x1245",
    "gfx.driver-init.feature-d2d": true,
    "gfx.crash-guard.status.d3d9video": 2,
    "gfx.crash-guard.status.d3d11layers": 2,
    "media.gmp-eme-adobe.lastUpdate": 1459940562,
    "media.autoplay.enabled": false,
    "media.gmp-gmpopenh264.version": "1.5.3",
    "media.gmp-gmpopenh264.lastUpdate": 1459940562,
    "media.gmp-eme-adobe.abi": "x86-msvc-x64",
    "media.benchmark.vp9.fps": 326,
    "media.hardware-video-decoding.failed": false,
    "media.gmp-eme-adobe.version": "17",
    "media.gmp-gmpopenh264.abi": "x86-msvc-x64",
    "media.gmp-manager.buildID": "20160405030214",
    "media.gmp-manager.lastCheck": 1459941715,
    "network.cookie.prefsMigrated": true,
    "network.predictor.cleaned-up": true,
    "places.database.lastMaintenance": 1459508796,
    "places.history.expiration.max_pages": "150000",
    "places.history.expiration.transient_current_max_pages": 45658,
    "plugin.importedState": true,
    "plugin.disable_full_page_plugin_for_types": "application/pdf",
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_orientation": 0,
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_colorspace": "",
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_headercenter": "",
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_scaling": "  1,00",
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_page_delay": 50,
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_headerright": "&U",
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_margin_bottom": "0.5",
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_edge_right": 0,
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_downloadfonts": false,
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_oddpages": true,
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_bgimages": false,
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_unwriteable_margin_left": 0,
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_footerleft": "&PT",
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_plex_name": "",
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_edge_bottom": 0,
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_paper_size_unit": 1,
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_paper_data": 9,
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_headerleft": "&T",
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_margin_right": "0.5",
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_edge_left": 0,
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_unwriteable_margin_bottom": 0,
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_in_color": true,
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_unwriteable_margin_right": 0,
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_unwriteable_margin_top": 0,
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_bgcolor": false,
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_resolution_name": "",
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_edge_top": 0,
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_evenpages": true,
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_shrink_to_fit": true,
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_duplex": 1515870810,
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_paper_height": " 11,00",
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_to_file": false,
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_paper_name": "",
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_reversed": false,
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_footerright": "&D",
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_paper_size_type": 0,
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_margin_top": "0.5",
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_footercenter": "",
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_resolution": 1515870810,
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_command": "",
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_margin_left": "0.5",
    "print.printer_hp_LaserJet_1010_HB_(1._másolat).print_paper_width": "  8,50",
    "privacy.sanitize.migrateFx3Prefs": true,
    "privacy.sanitize.migrateClearSavedPwdsOnExit": true,
    "security.sandbox.content.tempDirSuffix": "{bc17d9b3-46a3-416e-99e5-477ea848fbfb}",
    "services.sync.declinedEngines": "",
    "storage.vacuum.last.places.sqlite": 1456999149,
    "storage.vacuum.last.index": 1,
    "ui.osk.debug.keyboardDisplayReason": "IKPOS: Touch screen not found."
  },
  "lockedPreferences": {},
  "javaScript": {
    "incrementalGCEnabled": true
  },
  "accessibility": {
    "isActive": false,
    "forceDisabled": 0
  },
  "libraryVersions": {
    "NSPR": {
      "minVersion": "4.12",
      "version": "4.12"
    },
    "NSS": {
      "minVersion": "3.23 Basic ECC",
      "version": "3.23 Basic ECC"
    },
    "NSSUTIL": {
      "minVersion": "3.23",
      "version": "3.23"
    },
    "NSSSSL": {
      "minVersion": "3.23 Basic ECC",
      "version": "3.23 Basic ECC"
    },
    "NSSSMIME": {
      "minVersion": "3.23 Basic ECC",
      "version": "3.23 Basic ECC"
    }
  },
  "userJS": {
    "exists": false
  },
  "crashes": {
    "submitted": [],
    "pending": 17
  },
  "extensions": [
    {
      "name": "Add-ons Manager - Version Number",
      "version": "1.1",
      "isActive": true,
      "id": "AMVersionNumber@Aris_CTRdev"
    },
    {
      "name": "Another Restart",
      "version": "0.0.2",
      "isActive": true,
      "id": "@anotherrestart"
    },
    {
      "name": "Change Profile's Window Icons",
      "version": "1.5.2.1-signed",
      "isActive": true,
      "id": "change-window-icon@makyen.foo"
    },
    {
      "name": "Firefox Hello Beta",
      "version": "1.2.4",
      "isActive": true,
      "id": "loop@mozilla.org"
    },
    {
      "name": "Multi-process staged rollout",
      "version": "1.0",
      "isActive": true,
      "id": "e10srollout@mozilla.org"
    },
    {
      "name": "Pocket",
      "version": "1.0",
      "isActive": true,
      "id": "firefox@getpocket.com"
    },
    {
      "name": "Greasemonkey",
      "version": "3.7",
      "isActive": false,
      "id": "{e4a8a97b-f2ed-450b-b12d-ee082ba24781}"
    },
    {
      "name": "ImageHost Grabber",
      "version": "1.6.5.5.1-signed",
      "isActive": false,
      "id": "{E4091D66-127C-11DB-903A-DE80D2EFDFE8}"
    },
    {
      "name": "Mozilla Archive Format",
      "version": "4.0b6",
      "isActive": false,
      "id": "{7f57cf46-4467-4c2d-adfa-0cba7c507e54}"
    },
    {
      "name": "Session Manager",
      "version": "0.8.1.12",
      "isActive": false,
      "id": "{1280606b-2510-4fe0-97ef-9b5a22eafe30}"
    }
  ],
  "experiments": [
    {
      "id": "displayport-tuning-nightly@experiments.mozilla.org",
      "name": "DisplayPort Size Tuning",
      "description": "Measuring the effect of different displayport sizes on checkerboarding.",
      "active": false,
      "endDate": 1457444293193,
      "detailURL": "",
      "branch": "group5"
    }
  ],
  "graphics": {
    "numTotalWindows": 1,
    "numAcceleratedWindows": 1,
    "windowLayerManagerType": "Direct3D 11",
    "windowLayerManagerRemote": true,
    "supportsHardwareH264": "Yes; Using D3D11 API",
    "adapterDescription": "NVIDIA GeForce GTS 450   ",
    "adapterVendorID": "0x10de",
    "adapterDeviceID": "0x1245",
    "adapterSubsysID": "00000000",
    "adapterRAM": "1024",
    "adapterDrivers": "nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um",
    "driverVersion": "10.18.13.6175",
    "driverDate": "1-22-2016",
    "adapterDescription2": "",
    "adapterVendorID2": "",
    "adapterDeviceID2": "",
    "adapterSubsysID2": "",
    "adapterRAM2": "",
    "adapterDrivers2": "",
    "driverVersion2": "",
    "driverDate2": "",
    "isGPU2Active": false,
    "direct2DEnabled": true,
    "directWriteEnabled": true,
    "directWriteVersion": "6.3.9600.18123",
    "webglRenderer": "Google Inc. -- ANGLE (NVIDIA GeForce GTS 450    Direct3D11 vs_5_0 ps_5_0)",
    "info": {
      "AzureCanvasBackend": "direct2d 1.1",
      "AzureCanvasAccelerated": 0,
      "AzureFallbackCanvasBackend": "cairo",
      "AzureContentBackend": "direct2d 1.1",
      "ApzWheelInput": 1,
      "ApzTouchInput": 1
    }
  }
}



PS:
I much preferred the old more obvious crash recovery page. At present I only get a restore last session button at the bottom the startpage without anny message. (And of course the tabs not being restored.)
Flags: needinfo?(dqeswn)
Summary: Firefox content processes crash during system shutdown. → Firefox fails to exit properly on system shutdown e10s=on
Flags: needinfo?(mconley)
Alright, one last thing to try avada - can you try dropping dom.ipc.processCount to 1, and see if you can still reproduce this?

When there are many content processes, we might not be doing a clean shutdown in time.
Flags: needinfo?(mconley)
(In reply to Mike Conley (:mconley) - Catching up on reviews / needinfos from comment #13)
> Alright, one last thing to try avada - can you try dropping
> dom.ipc.processCount to 1, and see if you can still reproduce this?
> 
> When there are many content processes, we might not be doing a clean
> shutdown in time.

You mean on nightly with the fix landed from bug 1260461? (Normally I'm using Aurora)

Otherwise I did it in comment 2.
(In reply to avada from comment #14)
> (In reply to Mike Conley (:mconley) - Catching up on reviews / needinfos
> from comment #13)
> > Alright, one last thing to try avada - can you try dropping
> > dom.ipc.processCount to 1, and see if you can still reproduce this?
> > 
> > When there are many content processes, we might not be doing a clean
> > shutdown in time.
> 
> You mean on nightly with the fix landed from bug 1260461? (Normally I'm
> using Aurora)
> 
> Otherwise I did it in comment 2.

Ah, I apologize - I'd lost that context.

Again, it sounds like there are multiple bugs being reported here. I'd like to tease those apart as best I can.

In this bug, let's not focus on the Session Manager add-on, nor the about:sessionrestore page showing at start-up (or perhaps you're seeing about:home with the "Restore Last Session" button).

For this bug, I want to focus strictly on crashes that occur when you choose to shut down Windows without having first told Firefox to shut down. Any other issues are superfluous and should be dealt with in other bugs.

I want to make sure I have my facts straight here on this one:

1) With a "test" profile (which I assume started from scratch), if you have a Nightly open and running with e10s enabled, quitting Windows results in the content process crashing, and Windows showing some kind of dialog
2) Normally you have dom.ipc.processCount cranked up to 33, but even with this set to 1, the problem still occurs.

Are (1) and (2) correct?

If so, can you try your testing profile in "Safe Mode"[1]? Does the problem persist in safe mode?

[1]: https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode
Okay. So I did testing with today's central build.

I couldn't reproduce any part of this on my test profile whether I had more than one content process or not. Whether I used session manager or didn't.

However on my main (heavy) profile with Session manager I almost always get a crashed session at next startup. Sometimes I didn't when I had only one content process

I couldn't reproduce any issues while using the built in session manager.

I tried to contact the addon author in the SM mozillazine thread, but he didn't react at all. He might have me blocked for some reason...
(In reply to Mike Conley (:mconley) - Catching up on reviews / needinfos from comment #15)

> 
> Ah, I apologize - I'd lost that context.
> 
> Again, it sounds like there are multiple bugs being reported here. I'd like
> to tease those apart as best I can.
> 
> In this bug, let's not focus on the Session Manager add-on, nor the
> about:sessionrestore page showing at start-up (or perhaps you're seeing
> about:home with the "Restore Last Session" button).
> For this bug, I want to focus strictly on crashes that occur when you choose
> to shut down Windows without having first told Firefox to shut down. Any
> other issues are superfluous and should be dealt with in other bugs.

Well, as per my previous comment there doesn't seem to be any issue with the the built in session manager now that bug 1260461 landed. I tested with logging out. I assume that should suffice.
(I always saw about:home. Is about:sessionrestore even used? I haven't seen it in ages.)

> I want to make sure I have my facts straight here on this one:
> 
> 1) With a "test" profile (which I assume started from scratch), if you have
> a Nightly open and running with e10s enabled, quitting Windows results in
> the content process crashing, and Windows showing some kind of dialog
> 2) Normally you have dom.ipc.processCount cranked up to 33, but even with
> this set to 1, the problem still occurs.
> 
> Are (1) and (2) correct?
> 
> If so, can you try your testing profile in "Safe Mode"[1]? Does the problem
> persist in safe mode?
> 
> [1]:
> https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-
> mode

This was the case before bug 1260461 was fixed. Now I can only reproduce any crashed sessions when I use Session Manager.
Flags: needinfo?(mconley)
Okay so I've been using aurora since the fix from bug 1260461 landed. (My main profile, with session manager)
It works much better than central. On central I got a crashed session after every shutdown. You could also tell that it won't be right during shutdown, because it finished so quickly, in a few seconds.

With Aurora I got mixed results. For the first wo shutdowns during normal usage it exited without an issue.
Now I tested a bit more and I got some other results too. One crashed session with the content processes crashing during shutdown.
A couple where the content processes crashed, but I got a normal session on next startup. (This is new)

It felt like if I had a tab still loading (gmail, because it loads for a long time) when I logged out, it was more likely to bring up issues.
(In reply to avada from comment #18)
> Okay so I've been using aurora since the fix from bug 1260461 landed. (My
> main profile, with session manager)
> It works much better than central. On central I got a crashed session after
> every shutdown. You could also tell that it won't be right during shutdown,
> because it finished so quickly, in a few seconds.
> 
> With Aurora I got mixed results. For the first wo shutdowns during normal
> usage it exited without an issue.
> Now I tested a bit more and I got some other results too. One crashed
> session with the content processes crashing during shutdown.
> A couple where the content processes crashed, but I got a normal session on
> next startup. (This is new)
> 
> It felt like if I had a tab still loading (gmail, because it loads for a
> long time) when I logged out, it was more likely to bring up issues.

To be clear avada, this is only if you are using the Session Manager add-on?
Flags: needinfo?(mconley) → needinfo?(dqeswn)
(In reply to Mike Conley (:mconley) - Needinfo me! from comment #19)
> (In reply to avada from comment #18)
> > Okay so I've been using aurora since the fix from bug 1260461 landed. (My
> > main profile, with session manager)
> > It works much better than central. On central I got a crashed session after
> > every shutdown. You could also tell that it won't be right during shutdown,
> > because it finished so quickly, in a few seconds.
> > 
> > With Aurora I got mixed results. For the first wo shutdowns during normal
> > usage it exited without an issue.
> > Now I tested a bit more and I got some other results too. One crashed
> > session with the content processes crashing during shutdown.
> > A couple where the content processes crashed, but I got a normal session on
> > next startup. (This is new)
> > 
> > It felt like if I had a tab still loading (gmail, because it loads for a
> > long time) when I logged out, it was more likely to bring up issues.
> 
> To be clear avada, this is only if you are using the Session Manager add-on?

(Sorry if it sounds like I'm repeating myself. I'm really just trying to boil this down to the most basic facts for this one bug.)
(In reply to Mike Conley (:mconley) - Needinfo me! from comment #19)
> 
> To be clear avada, this is only if you are using the Session Manager add-on?

Just now I could reproduce it without SM. Started the browser. Alt+tabbed through a couple tabs to get them to start loading, then logged out. (while the pages were still loading) I got the crashed content processes and the startpage with the recovery button on next startup.
Flags: needinfo?(dqeswn)
(In reply to avada from comment #21)
> (In reply to Mike Conley (:mconley) - Needinfo me! from comment #19)
> > 
> > To be clear avada, this is only if you are using the Session Manager add-on?
> 
> Just now I could reproduce it without SM. Started the browser. Alt+tabbed
> through a couple tabs to get them to start loading, then logged out. (while
> the pages were still loading) I got the crashed content processes and the
> startpage with the recovery button on next startup.

This was on Nightly? Or which version of Firefox were you able to reproduce this on?
Flags: needinfo?(dqeswn)
(In reply to Mike Conley (:mconley) - Needinfo me! from comment #22)
> This was on Nightly? Or which version of Firefox were you able to reproduce
> this on?

Still aurora.
Flags: needinfo?(dqeswn)
Can you post the current build id you're running, a potential fix was uplifted recently.
Flags: needinfo?(dqeswn)
You mean something other than the fix from bug 1260461?
(Naturally I'm aware of that since I reported that too)

Well, since aurora updates daily I doubt it's of much use. But here it is:

20160418004027

Built from https://hg.mozilla.org/releases/mozilla-aurora/rev/02b8dc35ec80a95dd4f1cdd5a4075718aed233f2

(If this is what you meant.)

It was an older build of course the last time I commented on this bug.
Flags: needinfo?(dqeswn)
(In reply to avada from comment #25)
> You mean something other than the fix from bug 1260461?
> (Naturally I'm aware of that since I reported that too)
> 
> Well, since aurora updates daily I doubt it's of much use. But here it is:
> 
> 20160418004027
> 
> Built from
> https://hg.mozilla.org/releases/mozilla-aurora/rev/
> 02b8dc35ec80a95dd4f1cdd5a4075718aed233f2
> 
> (If this is what you meant.)
> 
> It was an older build of course the last time I commented on this bug.

The fix (bug 1260461) landed 2016-04-13. Curious if you are still seeing this in builds after that date?
Depends on: 1260461
Yes, and I already told that, and I also shared my experiences. See #18, #21.
avada - are you able to reproduce this at all on Nightly? I'm having no luck with your STR (logging out during a long page load).
Flags: needinfo?(dqeswn)
Unreliably on both aurora and central right now.
It seems like the more and heavier are the loading pages (and the heavier the profile) it's more likely to happen.
I didn't get the crashing content processes though with central. (Might be a coincidence.)
Flags: needinfo?(dqeswn)
Okay, throwing some qawanted on this. I need some specific STR, as I can't seem to hit this.
Keywords: qawanted
Flags: needinfo?(rares.bologa)
Flags: needinfo?(rares.bologa) → needinfo?(mfunches)
QA Confirmation: Yes I can produce and repeat this with the steps listed below
1) Start Aurora Windows 8.1
2) Main windows about:support
3) Open new tab yahoo.com
4) Open a new link in new window
5) Open a new link in a new window
6) Verify: Refresh about:support it should display 3/3 Enabled by default
7) Verify: Open new tab for about:config and verify dom.ipc.processCount (value currently 1)
8) Open new tab for about:preferences and set Show my windows and tabs from last time in the startup area
9) Click on desktop and press Alt F4 and select Shut down [OK]
Results: Windows shuts down successfully
10) Repeat these steps change the dom.ipc.processCount to higher value, I applied 5 (Shift F2 > Restart)
11) Click on the desktop and press Alt F4 and select Shut Down
Results: Crash nsAppShell:EventWindow: plugin-container.exe - Application error
Different options to shut down ie: You may also select shut down via Windows Start icon>Power icon>Shut down and still get the crash. 
I also tested with dom.ipc.processCount set at 1 and Shut Down, Restart, Log Off etc... were all successful. 
Last: See Screen shot, as about:crashes does not display history
Flags: needinfo?(mfunches)
Attached image plugin-containerAppError.PNG (deleted) — 
Please let me know if additional investigation is needed, as I still have no recorded Report ID to send.
Okay, excellent. So to boil this down, Michelle - you were only able to reproduce with dom.ipc.processCount > 1? Or am I misreading that?
Flags: needinfo?(mfunches)
Your understanding is correct Mike.  
I could only reproduce when I manipulate the dom.ipc.processCount value, and to fully disclose:
I changed the value to 2 and I saw no crash message. (Very interesting because value 4 was also successful)
I changed value to 3 = Crash window was displayed.
I changed Value to 5 = Crash windows was display.

Also I should not presume "Aurora" here is the App Basic info
Version 	47.0a2
Build ID 	20160421004015
User Agent 	Mozilla/5.0 (Windows NT 6.3; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
OS 	Windows_NT 6.3 x86
Flags: needinfo?(mfunches)
Okay, thank you Michelle.

Now, back to avada:

Speaking strictly about shutdown crashes, when you have dom.ipc.processCount = 1, do you see any on either Nightly or Aurora with no add-ons installed?
Flags: needinfo?(dqeswn)
(In reply to Mike Conley (:mconley) - Needinfo me! from comment #35)
> Okay, thank you Michelle.
> 
> Now, back to avada:
> 
> Speaking strictly about shutdown crashes, when you have dom.ipc.processCount
> = 1, do you see any on either Nightly or Aurora with no add-ons installed?

Nope. I don't consider it a realistic situation though.
Flags: needinfo?(dqeswn)
(In reply to avada from comment #36)
> (In reply to Mike Conley (:mconley) - Needinfo me! from comment #35)
> > Okay, thank you Michelle.
> > 
> > Now, back to avada:
> > 
> > Speaking strictly about shutdown crashes, when you have dom.ipc.processCount
> > = 1, do you see any on either Nightly or Aurora with no add-ons installed?
> 
> Nope. I don't consider it a realistic situation though.

Okay, great.

Still with dom.ipc.processCount = 1, without add-ons, are you able to get occurrences where after a Windows Logout with Firefox still running, Firefox starts but is unable to automatically restore your session?
Flags: needinfo?(dqeswn)
(In reply to Mike Conley (:mconley) - Needinfo me! from comment #37)
> (In reply to avada from comment #36)
> > (In reply to Mike Conley (:mconley) - Needinfo me! from comment #35)
> > > Okay, thank you Michelle.
> > > 
> > > Now, back to avada:
> > > 
> > > Speaking strictly about shutdown crashes, when you have dom.ipc.processCount
> > > = 1, do you see any on either Nightly or Aurora with no add-ons installed?
> > 
> > Nope. I don't consider it a realistic situation though.
> 
> Okay, great.
> 
> Still with dom.ipc.processCount = 1, without add-ons, are you able to get
> occurrences where after a Windows Logout with Firefox still running, Firefox
> starts but is unable to automatically restore your session?

I didn't get anything abnormal
Flags: needinfo?(dqeswn)
(In reply to avada from comment #38)
> (In reply to Mike Conley (:mconley) - Needinfo me! from comment #37)
> > (In reply to avada from comment #36)
> > > (In reply to Mike Conley (:mconley) - Needinfo me! from comment #35)
> > > > Okay, thank you Michelle.
> > > > 
> > > > Now, back to avada:
> > > > 
> > > > Speaking strictly about shutdown crashes, when you have dom.ipc.processCount
> > > > = 1, do you see any on either Nightly or Aurora with no add-ons installed?
> > > 
> > > Nope. I don't consider it a realistic situation though.
> > 
> > Okay, great.
> > 
> > Still with dom.ipc.processCount = 1, without add-ons, are you able to get
> > occurrences where after a Windows Logout with Firefox still running, Firefox
> > starts but is unable to automatically restore your session?
> 
> I didn't get anything abnormal

Great, okay.

Still with dom.ipc.processCount set to 1, are you able to get crashes or failed session restorations with the Session Manager add-on enabled?
Flags: needinfo?(dqeswn)
You mean with just only SM?
So still testing with multiple pages loading, on second try I got a crashed content process, but no crashed session showing up in SM.
On a later try I got something weird. The logout hung for a while, the windows went back to the desktop on its own (which never happened before), then aurora crashed ( https://crash-stats.mozilla.com/report/index/cc36a5bf-df34-427d-af30-a08e92160423 )
It might be just a coincidene though, since something like this never happened before.

Also now I see an even newer crash report appearing even though there wasn't any sign of a crash: https://crash-stats.mozilla.com/report/index/d3402740-e53c-436e-9e99-48d0b2160423


For both with and without SM case with a single content process I had occasions where the shutdown lasted very long. Like more than a minute.
Flags: needinfo?(dqeswn)
Okay, so the crashed content process with multiple pages loading with SessionManager enabled is what I think we should focus this bug on.

Re-assigning to the Add-ons evangelism component - perhaps we can enlist the help of the add-on author.
Component: General → Add-ons
Product: Firefox → Tech Evangelism
Summary: Firefox fails to exit properly on system shutdown e10s=on → SessionManager add-on causes Firefox to fail to exit properly on system shutdown while pages are loading with e10s enabled
(In reply to Mike Conley (:mconley) - Needinfo me! from comment #41)
> Okay, so the crashed content process with multiple pages loading with
> SessionManager enabled is what I think we should focus this bug on.
> 
> Re-assigning to the Add-ons evangelism component - perhaps we can enlist the
> help of the add-on author.

I guess someone should contact him. My attempts on mozillazine failed.
Removing qawanted keyword: Reference comment 31, also marking as new.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: qawanted
Priority: -- → P2
Whiteboard: triaged
If you will have time, please look on this bug.
Flags: needinfo?(morac99-firefox2)
I'm not seeing anything unusual when running Session Manager on the 20160706030233 Windows 64 bit nightly build with multi-process enabled.  I just shut down Windows with Firefox running and didn't get a crash dialog or anything else when I ran it after booting back up.

Avada, can you enable logging in the Session Manager Logging options and reproduce your issue and then paste the log here.  If you enable "log shutdown state" make sure you don't have any personal data in the logs.  It might be better to just leave that disabled.
Flags: needinfo?(morac99-firefox2)
ni'ing avada for comment 45.
Flags: needinfo?(dqeswn)
I still get regular crashes on 47 with multi-process enabled, with several content processes.
(In reply to Michael Kraft [:morac] from comment #45)

> I'm not seeing anything unusual when running Session Manager on the
> 20160706030233 Windows 64 bit nightly build with multi-process enabled.  I

Do you also have dom.ipc.processCount > 1?
Flags: needinfo?(dqeswn)
(In reply to avada from comment #47)
> I still get regular crashes on 47 with multi-process enabled, with several
> content processes.
> (In reply to Michael Kraft [:morac] from comment #45)
> 
> > I'm not seeing anything unusual when running Session Manager on the
> > 20160706030233 Windows 64 bit nightly build with multi-process enabled.  I
> 
> Do you also have dom.ipc.processCount > 1?

I have it set to 1 since that is the default and comment #40 indicated the problem was happening with the value set to 1.
Attached file SM log July-07 (deleted) — 
Well, I had a crash during shutdown. So here's the log. for that timeframe.
I removed the line with the personal data.

It's from my main profile. Maybe sometime I get myself to test with a test profile. Though, to be honest I'm quite fed up with testing for this shutdown bug.
Hi!
Here's another one. There was a crash again at shutdown. I only get one crash notifications on shutdown these days, so maybe only one of them crashes? Or the others are not caught. I can't say.

Also still SM can't restore a crashed session on startup. Nothing is restored. I have to open the SM window manually and try again for the session to get restored.
(In reply to avada from comment #50)
> Created attachment 8768759 [details]
> another log, the second session ended with a crashed content process on
> shutdown
> 
> Hi!
> Here's another one. There was a crash again at shutdown. I only get one
> crash notifications on shutdown these days, so maybe only one of them
> crashes? Or the others are not caught. I can't say.
> 
> Also still SM can't restore a crashed session on startup. Nothing is
> restored. I have to open the SM window manually and try again for the
> session to get restored.

From this log it doesn't look like Firefox shut down correctly.  There were no "quit-application-requested" notifications sent.

Just as a FYI, Session Manager uses the SessionStore crash detection built into Firefox so if Session Manager is reporting a crash, it's because Firefox was not shut down correctly.  

I don't believe this bug has anything to do with Session Manager since Session Manager was never even notified that Firefox was shutting down.  

There are dozens of other addons enabled, I would disable them and see if this is still a problem.
(In reply to Michael Kraft [:morac] from comment #51)
> I don't believe this bug has anything to do with Session Manager since
> Session Manager was never even notified that Firefox was shutting down.  

I see. Well, it wouldn't be as painful if SM could successfully restore a crashed session on the first try. Which it can't
Okay, so if it's not an SM issue I don't know what it is.
Should we, re-name it again?
Flags: needinfo?(mconley)
Yes, though I don't exactly know what to rename it to until we've narrowed in on which add-on is causing the problem (or perhaps it's a combination of add-ons).
Flags: needinfo?(mconley)
If it's in fact any addons is to blame. Everything was working fine for years before this new fancy shutdown method ruined it all.
Now I'm plagued with crashed content processes 90% of the time on shutdown.
I just renamed it into a more generic thing, since apparently no-one knows what's actually wrong.
Component: Add-ons → Untriaged
Product: Tech Evangelism → Core
Summary: SessionManager add-on causes Firefox to fail to exit properly on system shutdown while pages are loading with e10s enabled → Firefox fails to exit properly on system shutdown with e10s enabled
So things seem to have evolved as such I don't get the windows' crash prompt on shutdown. Neither crashed session. But I do get spammed by alerts of unsent crash reports.
Hi avada, related to your last comment, when you get the alert for unsent crash report, can you please try to send the crash report. Is this crash having same signature as the ones you had when reporting this bug?
Flags: needinfo?(dqeswn)
(In reply to Brindusa Tot[:brindusat] from comment #58)
> Hi avada, related to your last comment, when you get the alert for unsent
> crash report, can you please try to send the crash report. Is this crash
> having same signature as the ones you had when reporting this bug?

No clue. I already hid these notifications.

Though looking at the last couple reports, all of them have "IPCError-browser | ShutDownKill"

These:
bp-fd6fd223-3620-4d77-a665-e3bc12161215
	16. 12. 15.	11:20
bp-17bd5361-cd7c-47c4-af03-b52122161214
	16. 12. 14.	20:48
bp-c2ccbd85-ef28-4b70-bb2f-e8bbc2161214
	16. 12. 14.	11:41
bp-381509a5-6cc6-4a61-96b7-be4a42161214
	16. 12. 14.	2:54
Flags: needinfo?(dqeswn)
The crash signatures mentioned in previous comment 59(IPCError-browser | ShutDownKill) are different then the ones initially reported(ConsoleCopyStringToBuffer). Looking at the crashing treads for the two signatures, appears that have common sources. 

Mike, when have some time, could you please take a look and see if the two are related? Or is this a new bug?
Flags: needinfo?(mconley)
The signatures are different because we're force-killing the content process at two different points, but the overall effect is, I think, the same - the parent is forcibly killing the content process because it's taking too long to shut down.

That's a general problem with no single fix. I've marked this bug blocking the shutdownkill meta bug where more of these bugs also live.
Blocks: shutdownkill
Flags: needinfo?(mconley)
Thank you Mike. For a better tracking moving this to Core - IPC.
Component: Untriaged → IPC
Component: IPC → DOM: Content Processes
Still reproducible?
With Firefox 57 only WebExtensions are permitted and are, by default, e10s compatible.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: