This bug was filed from the Socorro interface and is report bp-0be68873-930f-4a28-9a9b-da51f2160711. ============================================================= Every time I restart Nightly 50 or Aurora 49 with e10s, I get the "You have an unsubmitted crash reports" notification. The crash reports are almost all "Crash in IPCError-browser | ShutDownKill" If I disable most of my add-ons, then the shutdown crashes go away. I was unable to isolate the problem to one particular add-on, but I have a set of 5–6 add-ons that reliably cause the shutdown crashes: Bugzilla Tweaks BugzillaJS geckoprofiler GitHub Hovercard GitHub Real Names

suspect gecko profiler... important to people that depend on - but smaller number than top issues. nightly through beta has the unsubmitted crash report errors.....not release...

I think the problem has more to do with the number of add-ons enabled. I see the problem even with gecko profiler disabled if I have other add-ons enabled.

I get this every shutdown, if I have three addons enabled. All three alone, or in combinations of two, will not trigger the shutdown crashes. The addons are: uBlock Origin 1.76 Classic Theme Restorer 1.5.5beta2 Close Tab by Double Click 1.14.1-signed.1-signed All were installed from AMO.

Example crash: https://crash-stats.mozilla.com/report/index/61efd493-f057-48f0-bc64-45a1c2160712

(In reply to timbugzilla from comment #3) > I get this every shutdown, if I have three addons enabled. All three alone, > or in combinations of two, will not trigger the shutdown crashes. > > The addons are: > > uBlock Origin 1.76 > Classic Theme Restorer 1.5.5beta2 > Close Tab by Double Click 1.14.1-signed.1-signed Was this with a clean profile? FWIW, I was not able to reproduce the shutdown crash with those add-ons (in a clean profile). I have session restore enabled for about 50 tabs. I "refreshed" my profile on the about:support page and reinstalled all my add-ons and I haven't been able to reproduce my shutdown crash. So perhaps there is some bad profile state that is causing the add-ons to hang on shutdown? It might be interesting to compare before and after copies of your user profile files after "refreshing" your profile to see which prefs or files changed.

Not with a fresh profile. Normally it produces the crash after a short time of browsing, but the most recent crash took ~ 30 mins to of browsing to trigger. It then went back to crashing quickly. Will try with a clean profile.

Both FireFox 48 and 47 are also affected; for months, no matter what I do, I always end up with this crash during every shutdown. For this reason, for example, tabs with YouTube videos do not remember the last playback position after restart -- apparently because this information should have been stored at later point than those crashes happen. I was also unable to reproduce the issue with simple set up neither in FF 48, nor in FF 47.

Crash volume for signature 'IPCError-browser | ShutDownKill': - esr (version 45): 16 crashes from 2016-04-07. Crash volume on the last weeks: Week N-1 Week N-2 Week N-3 Week N-4 Week N-5 Week N-6 Week N-7 - nightly 5966 8216 6846 5875 5644 5988 3365 - aurora 12518 13245 13035 14496 12750 10399 1721 - beta 189 225 171 117 145 103 22 - release 166 170 131 143 99 101 23 - esr 0 0 5 2 3 1 3 Affected platforms: Windows, Mac OS X, Linux

I can reproduce the crash with Tab Memory Usage add-on. Steps to reproduce: 1. Install extension https://addons.mozilla.org/en-US/firefox/addon/tab-memory-usage/. 2. Open the pages from https://dl.dropboxusercontent.com/u/95157096/85f61cf7/yk8ib5w829.html. 3. Wait until it is fully loaded. 4. Exit Browser and restart. Crash report: bp-c5f648c0-d195-4d0a-b1bc-8ecfb2160928 Regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bb8d6034f5f2&tochange=643589c3ef94 Suspect: bug 1103036

Redirecting to billm - hey billm, does the regression range in comment 9 look plausible? Anything in there jump out as a probable cause? Perhaps bug 1103036, as blinky suspects?

I believe that the shutdown timer was broken before bug 1103036. So it certainly makes sense. Before bug 1103036 we would have just hung forever waiting for the child to shut down.

Also, I'm afraid I'm not able to reproduce the STR in bug comment 9.

(In reply to Bill McCloskey (:billm) from comment #12) > Also, I'm afraid I'm not able to reproduce the STR in bug comment 9. I can still reproduce this bug, See https://dl.dropboxusercontent.com/u/95157096/85f61cf7/7o0lca7kbw.mp4. Crash report: bp-9619588d-ea8b-4b9f-ae4e-651262161004

Hi :billm, Can you help shed some light here or help find an owner for this bug because this crash growing so fast?

Clearing the priority field, this cannot be a P4.

I'm going to dupe this over to bug 1279293. There's a lot more discussion there.