Closed Bug 1103399 Opened 10 years ago Closed 10 years ago

e10s - "tab crashed" making Nightly mostly useless

Categories

(Firefox :: Untriaged, defect)

Product:
Firefox
Component:
Untriaged
Version:
37 Branch
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
e10s ? ---

People

(Reporter: u123541, Unassigned)

References

Details

Attachments

(2 files)

FF1103399
(deleted), text/plain
Details
FF1103399a
(deleted), text/plain
Details 
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20141113143407

Steps to reproduce:

Tabs crash very  often.  When it happens, most of the other tabs which were fine are replaced with the "tab crashed" page.

[Using FF33.1.1/Wine to report]


Actual results:

Got:
   Tab crashed
   Well, this is embarrassing. We tried to display this Web page, but it's not responding.
   Try again
Hit Try again; but usually no response.  Switching to any other tab: switch occurs; but page just leaves this same error display up -- often no way out except to restart.

On konsole, get LOTS of these:

!!! [Core] updateMenus(): [Exception... "Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsIProperties.get]"  nsresult: "0x80004002 (NS_NOINTERFACE)"  location: "JS frame :: file:///home/pfortin/.mozilla/firefox/iowvrjx2.default-1404854812966/extensions/%7Bb9db16a4-6edc-47ec-a1f4-b86292ed211d%7D/components/dhCore.js :: Core.prototype.updateMenus :: line 498"  data: no]

!!! [Core] cleanupEntriesForDocument: [Exception... "Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsIProperties.get]"  nsresult: "0x80004002 (NS_NOINTERFACE)"  location: "JS frame :: file:///home/pfortin/.mozilla/firefox/iowvrjx2.default-1404854812966/extensions/%7Bb9db16a4-6edc-47ec-a1f4-b86292ed211d%7D/components/dhCore.js :: Core.prototype.cleanupEntriesForDocument :: line 336"  data: no]



Expected results:

1. Try again didn't
2. switching to other windows or tabs -- every page has either "tabs crashed" or the new spinner.
Can you reproduce this without the downloadhelper add-on?
Blocks: e10s
tracking-e10s: --- → ?
Flags: needinfo?(pf)
Summary: "tab crashed" making Nightly mostly useless → e10s - "tab crashed" making Nightly mostly useless
1. why did you add e10s to the subject?  When e10s was first introduced, I turned it off -- I think because it killed ability to print.
2. the new spinner is VERY aggravating; since it was added, random problems such as this crash have been creeping in more often -- these crashes seem to have been temporary, downloadhelper didn't change that I know of.

Closing for now since these crashes occurred on a specific nightly.

Argh!  I forgot to add the specific Linux Nightly that was crashing...  now on 36.0a1 (2014-11-22) which is not crashing at the moment.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Flags: needinfo?(pf)
Resolution: --- → WORKSFORME
Hello Pierre,

(In reply to Pierre Fortin from comment #2)
> 1. why did you add e10s to the subject?

e10s is the process separation project that, among other things, allows tabs to crash instead of the whole browser to crash. Because you were experiencing a crashed tab, we knew you must be using e10s. The [e10s] string in the summary allows us to more easily find and triage your bug for folks working on making e10s better.

> When e10s was first introduced, I
> turned it off -- I think because it killed ability to print.

It was recently enabled by default on Nightly, which is probably why you saw it again. Printing support for Linux is being tracked in bug 1090448.

> 2. the new spinner is VERY aggravating; since it was added, random problems
> such as this crash have been creeping in more often -- these crashes seem to
> have been temporary, downloadhelper didn't change that I know of.

The spinner is indeed aggravating, and we're working on fixing it in various bugs. Bug 1090430, for example. Bug 1075122 was recently fixed that addresses some of the bad cases.

> 
> Closing for now since these crashes occurred on a specific nightly.
> 
> Argh!  I forgot to add the specific Linux Nightly that was crashing...  now
> on 36.0a1 (2014-11-22) which is not crashing at the moment.

Glad to know we're making it better. :)

Thanks for the report.
Re-opened -- it's back...  Once the "tab crashed" appears, every other tab shows the same. "Try again" doesn't seem to do anything, except the URL is cleared.  Re-entering the URL and hitting Enter just stays at "tab crashed" and the URL is cleared again.  Requires restart to restore use...  
This bug and the spinner are really aggravating given the number of FF windows/tabs I have open (25, 176, 7, 2, 8, 9, 23, 3, 12, 93)...
Status: RESOLVED → UNCONFIRMED
OS: Windows 7 → Linux
Resolution: WORKSFORME → ---
Can you link to some crash reports? (look in about:crashes)
Flags: needinfo?(pf)
What's the procedure?  Just attach the RAW output?  Or just:
bp-221e21dd-72f9-4119-a46f-f5ef42141125
bp-5d3f4329-6911-43d2-99ca-dd8f82141125
which are in the "submitted" folder.

That said, are these reports related to "tab crashed" -- i.e., this type of crash is not like a segfault, or other fault+die crash...?
Flags: needinfo?(pf)
(In reply to Pierre Fortin from comment #6)
> What's the procedure?  Just attach the RAW output?  Or just:
> bp-221e21dd-72f9-4119-a46f-f5ef42141125
that's bug 1104160
> bp-5d3f4329-6911-43d2-99ca-dd8f82141125
stack here is:
0 	libmozalloc.so 	mozalloc_abort(char const*) 	memory/mozalloc/mozalloc_abort.cpp
1 	libxul.so 	NS_DebugBreak 	xpcom/base/nsDebugImpl.cpp
2 	libxul.so 	mozilla::dom::ContentChild::ProcessingError(mozilla::ipc::HasResultCodes::Result) 	dom/ipc/ContentChild.cpp
3 	libxul.so 	mozilla::ipc::MessageChannel::MaybeHandleError(mozilla::ipc::HasResultCodes::Result, IPC::Message const&, char const*) 	ipc/glue/MessageChannel.cpp
4 	libxul.so 	mozilla::ipc::MessageChannel::OnMaybeDequeueOne() 	ipc/glue/MessageChannel.cpp
5 	libxul.so 	MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const&) 	ipc/chromium/src/base/message_loop.cc
6 	libxul.so 	MessageLoop::DoWork() 	ipc/chromium/src/base/message_loop.cc
7 	libxul.so 	mozilla::ipc::MessagePumpForChildProcess::Run(base::MessagePump::Delegate*) 	ipc/glue/MessagePump.cpp
8 	libxul.so 	MessageLoop::Run() 	ipc/chromium/src/base/message_loop.cc
9 	libxul.so 	nsBaseAppShell::Run() 	widget/nsBaseAppShell.cpp
10 	libxul.so 	XRE_RunAppShell 	toolkit/xre/nsEmbedFunctions.cpp
11 	libxul.so 	MessageLoop::Run() 	ipc/chromium/src/base/message_loop.cc
12 	libxul.so 	XRE_InitChildProcess 	toolkit/xre/nsEmbedFunctions.cpp
13 	plugin-container 	content_process_main(int, char**) 	ipc/contentproc/plugin-container.cpp
Ø 14 	libc-2.18.so 	libc-2.18.so@0x21c84 	
15 	plugin-container 	_init 	
16 	plugin-container 	malloc_good_size 	memory/build/replace_malloc.c
17 	plugin-container 	__libc_csu_fini 	
18 	plugin-container 	malloc_good_size 	memory/build/replace_malloc.c
19 	plugin-container 	_start 	


> which are in the "submitted" folder.
> 
> That said, are these reports related to "tab crashed" -- i.e., this type of
> crash is not like a segfault, or other fault+die crash...?

Bill, anything you want to do with that stack?
Flags: needinfo?(wmccloskey)
> Bill, anything you want to do with that stack?

I haven't seen that one before. It means that we received a message that doesn't match any known message type. I'm not sure how that could happen.
Flags: needinfo?(wmccloskey)
BTW, those 2 crashes happened at the same time:
-rw-r--r-- 1 pfortin pfortin 49 Nov 25 11:42 bp-221e21dd-72f9-4119-a46f-f5ef42141125.txt
-rw-r--r-- 1 pfortin pfortin 49 Nov 25 11:42 bp-5d3f4329-6911-43d2-99ca-dd8f82141125.txt
Most of my e10s tab crashes are centered around flash videos.  One site that tab crashes occur pretty regularly is weather.com.


Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:36.0) Gecko/20100101 Firefox/36.0
36.0a1 (2014-11-25) -- When I restart FF, most tabs are in "tab crashed" state when I switch to them...  Even this bug page which has no flash on it.  Just now, switched to this window which had another tab selected. This bug was on a tab labelled "11033..."; but when I clicked on it, "tab crashed" was displayed. Clicked on "try again" and an "enter bug" page appeared...  had to enter the bug number in search to get back to it.
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:36.0) Gecko/20100101 Firefox/36.0 ID:20141127030208 CSet: cef590a6f946

I gave up trying to run e10s because of the tab crash problem. Just now I tried it with a clean test profile, imported only my bookmarks to it. Tried a few pages without problems, including the Adobe Flash test page - the Flash animation didn't cause a crash. Went to yahoo.com, immediate tab crash.
Hey greenknight,

Could you also provide some crash reports for us? They'll be in about:crashes - thanks!
Flags: needinfo?(spencerselander)
Most of them didn't generate a crash report, but there is this one: 
https://crash-stats.mozilla.com/report/index/bp-e699b03f-4967-4042-b513-5207b2141206
Flags: needinfo?(spencerselander)
I should add that I'm using e10s now with dom.ipc.processCount in about:config set to 16. No crashes, but it creates a new problem where links open a blank tab while the page opens in the original tab. I'm middle-clicking all links to work around this.
Flags: needinfo?(mconley)
More info - Tried setting dom.ipc.processCount to 4, tab crash if I opened a 5th tab. Didn't crash all tabs like it had before, just the active tab. Increased the integer to more than enough for my tab usage, no more crashes.

I had the option set "open new windows in a tab instead", links that would open a new window then opened a new blank tab with focus, while the target of the link opened in the original tab. I've since tried unchecking that option, so those links open in a new window; that works correctly. Should I file a new bug for this?
This bug is kinda spiraling out - there are several different crash signatures in here, and several different approaches to getting into a crashy state.

It sounds like Pierre, the original reporter, was caught in a cycle where all of his tabs would crash, he'd "try again" to restore one, and one of the following would happen:

1) Nothing (bug 963358 should have fixed this case)
2) The URL bar would be cleared - my guess is that the tab is being reloaded, and then crashing immediately. This is likely an add-on.

greenknight sounds like he's hitting something different - it sounds like greenknight has dom.ipc.processCount cranked up, and is hitting a bug when content tries to open a link with target="_blank" or window.open. That's bug 1051969, which I've cc'd greenknight on.

I'm going to redirect this bug so that it's back addressing what Pierre is seeing.

Pierre - are you able to reproduce this problem with all of your add-ons disabled (note - please don't use Safe Mode, as this disables e10s. You'll need to manually disable all of your add-ons. Maybe copy the list of enabled add-ons in about:support so that you remember which ones to re-enable afterwards).
Flags: needinfo?(mconley) → needinfo?(pf)
I run Linux, so I've duplicated my .mozilla directory into a new userid.  Removed all the addons from 2nd instance.  However, today, I'm not seeing this problem in either instance (with and without addons) running 37.0a1 (2014-12-10)...
Will update this bug if it comes back...
Flags: needinfo?(pf)
Ok, yes, please re-open if/when you see this again. Thanks!
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → INCOMPLETE
Not fixed for me in Win 7. I reset dom.ipc.processCount back to 1, links to open in new tab, tried a link in Yahoo Mail, and got a tab crash. Doesn't happen consistently, haven't managed to trigger another one. Did get a crash report, though:
 https://crash-stats.mozilla.com/report/index/bp-2aadcd36-5115-4edb-8a25-9e88e2141211
(In reply to Spencer Selander [greenknight] from comment #20)
> Not fixed for me in Win 7. I reset dom.ipc.processCount back to 1, links to
> open in new tab, tried a link in Yahoo Mail, and got a tab crash. Doesn't
> happen consistently, haven't managed to trigger another one. Did get a crash
> report, though:
>  https://crash-stats.mozilla.com/report/index/bp-2aadcd36-5115-4edb-8a25-
> 9e88e2141211

That's interesting - are you able to reproduce that with all of your add-ons disabled?
Flags: needinfo?(spencerselander)
Mike, I left the 2nd instance (37.0a1 (2014-12-10) with all addons disabled) running on another desktop. When I checked it this morning, all(?)[1] tabs were displaying tab crashed. The first tat had the Tell Mozilla checkbox; but not the rest.  Since I wasn't interacting with this instance; maybe autorefresh on some pages was the trigger... Some tabs automatically reloaded (refreshed since that was quite fast?) while others needed me to click Try Again.

Looks like this: 
* some (currently displayed?) tab crashes
* tab crashed display with checkbox
* switch to another tab
* tab crashed w/o checkbox displays
* tab either:
  - auto-refreshes
  - requires clicking Try Again
  Both cases seem too fast for required network activity.

[1] Instance consists of 12 windows with many tabs -- see comment 4 for an idea -- I really stress any software I beta test... :)
Status: RESOLVED → UNCONFIRMED
Resolution: INCOMPLETE → ---
Version: 36 Branch → 37 Branch
I think I'm going to need more information - is there a certain set of sites that you can reliably reproduce this with that I can try?
Flags: needinfo?(pf)
With over 350 tabs open, that's hard to say...  but the ones that might be suspect are:
theblaze.com
slashdot.org
breitbart.com
drudge.com
twitchy.com
facebook.com (multiple tabs)
bugzilla.mozilla.org (multiple tabs)
google.com (many searches clicked through to results)

A clue that seems to be missed:  when one tab crashes, it sets up FF to display "tab crashed" on any window/tab I switch to...  there must be code that checks for a tab crash; but fails to restrict it to the tab that actually crashed...  Restrict the tab crash to the instance that actually crashed, and we might have a better chance at finding the cause...  With today's crash, I failed to notice which page was up when I switched to the desktop running the non-addon instance.

[FWIW, the new big spinner seems to be coded similarly...  it is the only thing that appears when FF is restarted, until I switch to another tab and back... repeat for each window.  My spinner report was closed as DUPL and 1090430 as fixed; but once closed as FIXED, is there a way to re-open?]
Flags: needinfo?(pf)
(In reply to Mike Conley (:mconley) - Needinfo me! from comment #21)
> (In reply to Spencer Selander [greenknight] from comment #20)
> > Not fixed for me in Win 7. I reset dom.ipc.processCount back to 1, links to
> > open in new tab, tried a link in Yahoo Mail, and got a tab crash. Doesn't
> > happen consistently, haven't managed to trigger another one. Did get a crash
> > report, though:
> >  https://crash-stats.mozilla.com/report/index/bp-2aadcd36-5115-4edb-8a25-
> > 9e88e2141211
> 
> That's interesting - are you able to reproduce that with all of your add-ons
> disabled?

Not so far, still trying. Not crashing as frequently now, only had one more tab crash even with addons enabled. That one happened when the Yahoo home page was loading, only one tab open, and had yet another signature: https://crash-stats.mozilla.com/report/index/bp-4f9b1535-5295-45d8-9bbf-ca6752141211
Flags: needinfo?(spencerselander)
Ok, greenknight - if that's the case, I'll assert that one of your add-ons was likely causing your crash. If you wouldn't mind, could you please re-enable them one by one to see which one it was, and file a new bug for it? That last crash you identified is bug 1105896.

Pierre - ok, if you're able to reproduce these crashes pretty regularly even with all of your add-ons disabled, I'd like to see more crash stacks from you. That'll (hopefully) help us narrow down on the cause. Thanks!
Flags: needinfo?(pf)
Attached file FF1103399 (deleted) — 
Switched to the test desktop where FF is simply sitting with no interaction from me.  It's in a tab crashed state on the tab viewing https://bugzilla.mozilla.org/show_bug.cgi?id=1090430
As stated earlier, this one has "Tell Mozilla..." checkbox. Clicked it and got the page.
Switching to other tabs gives the crash without the "Tell Mozilla.." part.
Flags: needinfo?(pf)
Hmmm...  the time stamp on the crash is 5:36pm which is about the exact time I switched desktops which would have forced a repaint...  just saying...
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:37.0) Gecko/20100101 Firefox/37.0 ID:20141212030201 CSet: 5288b15d22de

Can't trigger a tab crash in this build. Lots of temporary hangs, with high CPU use but not maxed out, sometimes with slow script notices. A couple of total browser crashes, but they were https://bugzilla.mozilla.org/show_bug.cgi?id=1073825

Been trying for 2 days to nail down the add-on causing the tab crash, but couldn't find any page that caused it consistently, which made it slow going. By disabling half the add-ons at a time, managed to narrow it down to 4, but couldn't get any further. With no more tab crashes to diagnose, I guess I'm done.
per comment 29. if you run into this again, please reopen, thanks!
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → WORKSFORME
This site always produces a tab crash in the past few days... https://sites.google.com/site/sonthakit/bookmarkfaviconchanger

Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:37.0) Gecko/20100101 Firefox/37.0
(In reply to Gary [:streetwolf] from comment #31)
> This site always produces a tab crash in the past few days...
> https://sites.google.com/site/sonthakit/bookmarkfaviconchanger
> 
> Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:37.0) Gecko/20100101 Firefox/37.0

Hey streetwolf - do your stacks in about:crashes match any of Pierre's in comment 6? If not, please file a new bug and Cc me. Thanks!
Attached file FF1103399a (deleted) — 
Left a 2nd instance of FF (all addons disabled) running on a separate desktop for several days.  When I switched to it, it was in a crashed state -- based on the crash time stamp, the crash occurred at the moment I switched to that desktop.

Differences this time:
1. Not only the visible tab had the Notify Mozilla check box; they all did.
2. Try Again returned a Try Again (w/o checkbox) ad infinitum.  FF was now in totally unusable state.
Gary's link in Comment #31 causes Nightly to crash for me with e10s disabled, consistently. The first time there was no crash report, but I did get one just now - session was not restored, though, reopened to a blank window:

https://crash-stats.mozilla.com/report/index/bp-ef975c9c-254f-4218-bbeb-6b5d42141222

With Firefox 24.0 it did not crash.
(In reply to Spencer Selander [greenknight] from comment #34)
> Gary's link in Comment #31 causes Nightly to crash for me with e10s
> disabled, consistently. The first time there was no crash report, but I did
> get one just now - session was not restored, though, reopened to a blank
> window:
> 
> https://crash-stats.mozilla.com/report/index/bp-ef975c9c-254f-4218-bbeb-
> 6b5d42141222
> 
> With Firefox 24.0 it did not crash.

Ok, with e10s disabled, then this is definitely not the same as Pierre's crash. I believe that's bug 1113980.
Crashes with add-ons disabled, too. Since it's another bug, if I come up with any more on this crash I'll post it in bug 1113980
Still getting tab crashes with e10s.  Non-e10s work fine.  

Over at https://forum.userstyles.org/ if I try to attach a file to a post I get a tab crash.  Non-e10s work fine.  Problem is not limited to this site only.
(In reply to Gary [:streetwolf] from comment #37)
> Still getting tab crashes with e10s.  Non-e10s work fine.  
> 
> Over at https://forum.userstyles.org/ if I try to attach a file to a post I
> get a tab crash.  Non-e10s work fine.  Problem is not limited to this site
> only.

I can't reproduce this (in e10s mode). Can you provide links to crash reports for these?
Flags: needinfo?(garyshap)
There are no crash reports produced. However, it appears that LastPass is causing the crashes because when I disable LP there are no crashes.  This is what I found in my browser log after a crash:

child process crashed or timedout lastpass.js:668:0
lpmanuallogins.length is 0
Flags: needinfo?(garyshap)
It appears a recent patch fixed the problem in comment 37.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: