1301464 - [e10s] [@ IPCError-browser | ShutDownKill ] Reddit Enhancement Suite extension

Status: RESOLVED DUPLICATE of bug 1279293

(Core :: DOM: Content Processes, defect)

Description

[bintoro]

A crash report is generated on startup when all of the following are true:
- multiprocessing is enabled
- the Reddit Enhancement Suite extension is enabled
- the restored session contains more than one tab.

https://crash-stats.mozilla.com/report/index/7c058963-5998-408e-8de0-bc8572160907
https://crash-stats.mozilla.com/report/index/9eaad5ab-e14e-4a43-83b1-c342b2160907

Both 50.0a2 and 51.0a1 are affected.

The session is eventually completely restored; the unsubmitted crash report notification is the only visible indication that something went wrong. Also, the RES extension seems to work just fine.

Comment 1

[Loic]

Are you sure about the STR?

Comment 2

[bintoro]

Okay, I have discovered some more information.

On my main profile, I tend to have browser.cache.disk.enable = false. Before reporting, I had already tried re-enabling the setting to see if it might have an effect. It didn't.

However, on a new test profile, I needed to both install RES and disable disk caching to reproduce. This time, the stack trace looked quite different:

https://crash-stats.mozilla.com/report/index/912139c3-7af6-4190-8bd0-6c03a2160908
https://crash-stats.mozilla.com/report/index/71a69b70-6f17-485e-9412-913c42160908

After experimenting with going between cache on and off, the crash began to seem somewhat sporadic. So I created a pristine profile for the third time and was eventually able to trigger a recurring crash without messing with the cache setting at all. Unfortunately, I haven't yet figured out a way to do so reliably, so disabling the disk cache looks like the best way to reproduce this at the moment.

Comment 3

[Kanchan Kumari QA]

Hello Bintoro,  I tested with both dirty and fresh profile with different cache settings, e10s on, many open tabs, and Reddit Enhancement Suite extension but couldn't reproduce the crash. Tested on

Version  51.0a1
Build ID  20160913030425
User Agent  Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:51.0) Gecko/20100101 Firefox/51.0

May I know what version you are on so that I can try reproducing on that specific version. Any additional info would be helpful too.

There has been a lot of the crashes reported with this signature which are not user-visible. See bug# 1279293 for more info.

Comment 4

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

No reply from the reporter and WFM per comment #3,
so duping this to bug #1279293.

Comment 5

[Tobias B. Besemer [:BesTo] (QA)]

Guess it's better to dup it to bug 1286053 because also a Extension-/Add-on-Bug and IMHO more likely the same reason.

Comment 6

[bintoro]

Sorry about the lack of response! The bug is difficult to reproduce consistently, and I haven't had time to investigate this as thoroughly as I would have liked to.

It turns out the phenomenon doesn't seem to be caused by a single factor such as RES or any setting (apart from e10s of course). It looks as though session restoration in some circumstances is too sluggish for the process manager's liking, and a tab gets killed. Increasing dom.ipc.tabs.shutdownTimeoutSecs to 10 eliminates the issue.

The reason I reported this as a separate bug is that this one clearly has to do with session restoration in particular, which I thought might be interesting.