1262081 - Main process disconnects from the Web Content process

Status: RESOLVED WORKSFORME

(Core :: General, defect)

Description

[Jovan Gerodetti]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160404004026

Steps to reproduce:

Firefox 47.0a2 (2016-04-04)
OS X 10.11.4 (15E65)

While doing web development, I use a couple of probably quite heavy websites at the same time. At least:
2 GMail tabs
1 Tab with Active Collab
1 Tab with our product
1 tab with telegram web


Actual results:

At indefinite time intervals all the tabs stop responding. I can still scroll but as soon as I switch to an other tab I just get the loading circle, no content is rendered. The "a website is slowing down...." dialog never appears. 
Only killing the Web Content process and reloading all the tabs works. 

I only experience this during development, but I don't really know why.

Comment 1

[Abe - QA (:Abe_LV)]

Jovan, I have tested this issue on latest nightly and aurora and could not reproduce it given the above information. 
Can you please retest this with safe mode, clean profile and disabled e10s?  In step-3 above, "our product" site is not mentioned, can you also check if the issue is specific to this site ?  Thanks

--
Version  48.0a1
Build ID  20160408030212
Update Channel  nightly
User Agent  Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:48.0) Gecko/20100101 Firefox/48.0
     and
Version  47.0a2
Build ID  20160404004026
Update Channel  aurora
User Agent  Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Firefox/47.0
OS  Darwin 15.2.0 x86-64

Comment 2

[Jovan Gerodetti]

Abe, today I keept the Browser console open, and when I encountered the described issue I got the following exception thrown in view-source:resource://devtools/shared/ThreadSafeDevToolsUtils.js

>"Handler function DebuggerClient.requester request callback threw an exception: TypeError: aBindings is >undefined
>Stack: VariablesViewController.prototype._populateWithEnvironmentBindings@resource://devtools/client/shared/widgets/VariablesViewController.jsm:467:5
>VariablesViewController.prototype._populateWithClosure/<@resource://devtools/client/shared/widgets/VariablesViewController.jsm:445:11
>DebuggerClient.requester/</<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/client/main.js:294:9
>exports.makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/ThreadSafeDevToolsUtils.js:101:14
>emitOnObject@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/event/core.js:112:9
>emit@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/event/core.js:89:38
>Request.prototype.emit@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/client/main.js:1232:29
>DebuggerClient.prototype.onPacket/emitReply@resource://gre/modules/commonjs/toolkit/loader.js -> >resource://devtools/shared/client/main.js:1016:29
>DevTools RDP*DebuggerClient.prototype.request@resource://gre/modules/commonjs/toolkit/loader.js -> >resource://devtools/shared/client/main.js:722:5
>DebuggerClient.requester/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/client/main.js:282:12
>exports.makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/ThreadSafeDevToolsUtils.js:101:14
>VariablesViewController.prototype._populateWithClosure@resource://devtools/client/shared/widgets/VariablesViewController.jsm:444:9
>VariablesViewController.prototype._populateProperties/</<@resource://devtools/client/shared/widgets/VariablesViewController.jsm:404:11
>DebuggerClient.requester/</<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/client/main.js:294:9
>exports.makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/ThreadSafeDevToolsUtils.js:101:14
>emitOnObject@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/event/core.js:112:9
>emit@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/event/core.js:89:38
>Request.prototype.emit@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/client/main.js:1232:29
>DebuggerClient.prototype.onPacket/emitReply@resource://gre/modules/commonjs/toolkit/loader.js -> >resource://devtools/shared/client/main.js:1016:29
>DevTools RDP*DebuggerClient.prototype.request@resource://gre/modules/commonjs/toolkit/loader.js -> >resource://devtools/shared/client/main.js:722:5
>DebuggerClient.requester/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/client/main.js:282:12
>exports.makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/ThreadSafeDevToolsUtils.js:101:14
>VariablesViewController.prototype._populateProperties/<@resource://devtools/client/shared/widgets/VariablesViewController.jsm:396:9
>DebuggerClient.requester/</<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/client/main.js:294:9
>exports.makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/ThreadSafeDevToolsUtils.js:101:14
>emitOnObject@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/event/core.js:112:9
>emit@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/event/core.js:89:38
>Request.prototype.emit@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/client/main.js:1232:29
>DebuggerClient.prototype.onPacket/emitReply@resource://gre/modules/commonjs/toolkit/loader.js -> >resource://devtools/shared/client/main.js:1016:29
>DevTools RDP*DebuggerClient.prototype.request@resource://gre/modules/commonjs/toolkit/loader.js -> >resource://devtools/shared/client/main.js:722:5
>DebuggerClient.requester/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/client/main.js:282:12
>exports.makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/ThreadSafeDevToolsUtils.js:101:14
>VariablesViewController.prototype._populateProperties@resource://devtools/client/shared/widgets/VariablesViewController.jsm:363:5
>VariablesViewController.prototype._populateFromObject@resource://devtools/client/shared/widgets/VariablesViewController.jsm:356:12
>VariablesViewController.prototype.populate@resource://devtools/client/shared/widgets/VariablesViewController.jsm:572:7
>VariablesViewController.prototype.setSingleVariable@resource://devtools/client/shared/widgets/VariablesViewController.jsm:706:19
>Tooltip.prototype.setVariableContent@resource://gre/modules/commonjs/toolkit/loader.js -> >resource://devtools/client/shared/widgets/Tooltip.js:634:5
>VariableBubbleView.prototype.showContents@chrome://devtools/content/debugger/views/variable-bubble-view.js:191:7
>VariableBubbleView.prototype._findIdentifier/<@chrome://devtools/content/debugger/views/variable-bubble-view.js:136:11
>resolve@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/deprecated-sync-thenables.js:40:40
>then@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/deprecated-sync-thenables.js:20:43
>resolve@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/deprecated-sync-thenables.js:72:11
>StackFrames.prototype.evaluate/<@chrome://devtools/content/debugger/debugger-controller.js:981:9
>eventSource/aProto.addOneTimeListener/l@resource://gre/modules/commonjs/toolkit/loader.js -> >resource://devtools/shared/client/main.js:68:7
>eventSource/aProto.emit@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/client/main.js:131:9
>ThreadClient.prototype._onThreadState@resource://gre/modules/commonjs/toolkit/loader.js -> >resource://devtools/shared/client/main.js:2211:35
>DebuggerClient.prototype.onPacket@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/client/main.js:992:7
>LocalDebuggerTransport.prototype.send/<@resource://gre/modules/commonjs/toolkit/loader.js -> >resource://devtools/shared/transport/transport.js:569:11
>exports.makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/ThreadSafeDevToolsUtils.js:101:14
>exports.makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/ThreadSafeDevToolsUtils.js:101:14
>Line: 467, column: 5"

Comment 3

[Mike Conley (:mconley) (:⚙️)]

Would it be possible to gather a performance profile from Firefox when it starts behaving this way? That will help us determine what it's doing when it should be showing you tab content:

https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem

Comment 4

[Jovan Gerodetti]

https://cleopatra.io/#report=9eab95a3e3080451087b2f3110d94c13311180ea

I recored this yesterday and stoped it after I encountered the issue. I will create an other one today.

Comment 5

[Mike Conley (:mconley) (:⚙️)]

This profile is highlighting two things:

1) The uBlock add-on is causing lots of sync IPC messages to come up from the content process due to the add-on shims.
2) The design.google.com website you're on is using some kind of webcomponents shim library that does expensive things on what I presume to be page load.

But uBlock dominates this profile.

Can you temporarily disable uBlock to see if that resolves the main issue for you? If so, we can transmute this into a uBlock bug, and perhaps work with the add-on author to avoid the shims.

Comment 6

[Jovan Gerodetti]

Today I disabled uBlock but the issue still occurs.
https://cleopatra.io/#report=565677330001d360d3c42e794e798856bba6263e

Comment 7

[Mike Conley (:mconley) (:⚙️)]

(In reply to Jovan Gerodetti from comment #6)
> Today I disabled uBlock but the issue still occurs.
> https://cleopatra.io/#report=565677330001d360d3c42e794e798856bba6263e

Interesting. I'm still seeing a bunch of shim usage here. Did you restart the browser after you disabled uBlock?

If not, can you give me a list of your enabled add-ons? Can you reproduce the problem with your add-ons disabled?

Comment 8

[Jovan Gerodetti]

I dissabled all my addons but it's still happening.

https://cleopatra.io/#report=249ff2912e2f75dd745a8cb2050407d367d98a47

Comment 9

[Mike Conley (:mconley) (:⚙️)]

There's not a lot of content process information in this profile - there are only a few samples for the content process.

There are no shim messages being sent in those samples, so that's a positive sign. If, however, you're still seeing your issue, can you try to keep the profiling running for just a little while longer before gathering?

Comment 10

[Jovan Gerodetti]

(In reply to Mike Conley (:mconley) - Needinfo me! from comment #9)
> There's not a lot of content process information in this profile - there are
> only a few samples for the content process.
> 
> There are no shim messages being sent in those samples, so that's a positive
> sign. If, however, you're still seeing your issue, can you try to keep the
> profiling running for just a little while longer before gathering?

Okay I will try to do so, but I always have to kill the content process before I can gather the data. Can this lead to profiling data losts?

Comment 11

[Mike Conley (:mconley) (:⚙️)]

(In reply to Jovan Gerodetti from comment #10)
> (In reply to Mike Conley (:mconley) - Needinfo me! from comment #9)
> > There's not a lot of content process information in this profile - there are
> > only a few samples for the content process.
> > 
> > There are no shim messages being sent in those samples, so that's a positive
> > sign. If, however, you're still seeing your issue, can you try to keep the
> > profiling running for just a little while longer before gathering?
> 
> Okay I will try to do so, but I always have to kill the content process
> before I can gather the data. Can this lead to profiling data losts?

Yes, that will get rid of any data that the content process would have given us, so I suppose that's less than useful.

If you get into that state, we might be able to get more information from OS X's Activity Monitor. If you open Activity Monitor and find the Nightly Web Content process that's locked up, you should be able to sample the process to give us a sense of what it's doing.

See: http://www.chriswrites.com/how-to-use-activity-monitor-master-class/ for some guidance if you've never gotten a process sample before.

Comment 12

[Comorasu Cristian]

Tested on Mac OS X 10.9.5, using the build from 2016-04-05, I was unable to reproduce this issue , also
tried with Firefox 47.0b3 and got the same result.
[testday-20160506]

Comment 13

[Jovan Gerodetti]

I also don't encounter this issue anymore, but I had to disable the tab auto unload addon and I want to check if that addon was causing the issue.

Comment 14

[Jovan Gerodetti]

Attachment: Analyse von „FirefoxDeveloperEdition Web Content“.txt

today I got stuck again. It was a different project but kind of the same behaviour. I hope this is useful.

Comment 15

[Mike Conley (:mconley) (:⚙️)]

Hm. It looks like here, the jsdebugger was opened, and was spinning some kind of nested event loop... and then a bunch of busy stuff happened with some JIT stuff...

Hey Eddy - do you know if there are other known bugs around where we hang the main process during this nested event loop for the jsdebugger?

Comment 16

[Eddy Bruel [:ejpbruel]]

(In reply to Mike Conley (:mconley) - (needinfo me!) from comment #15)
> Hm. It looks like here, the jsdebugger was opened, and was spinning some
> kind of nested event loop... and then a bunch of busy stuff happened with
> some JIT stuff...
> 
> Hey Eddy - do you know if there are other known bugs around where we hang
> the main process during this nested event loop for the jsdebugger?

The debugger API notifies the debugger server when a new source is introduced. When that happens, the debugger server has to (re)set any breakpoints we may have had for that source. It needs to do this synchronously, otherwise the debuggee could continue running past the breakpoint, before we get a chance to set it.

In the presence of source mapping, we need to asynchronously load the source map before we can figure out the actual location of each breakpoint. To prevent the debuggee from continuing in the meantime, we spin a nested event loop until we are done.

This mechanism is known to be very fragile, and has been a source of headaches in the past. For instance, loading a JSM can trigger the debugger, which enters a nested event loop, which then handles an event that loads the same JSM again. JSMs cannot be loaded reentrantly, so doing so crashes the browser.

If you're not using source maps, a quick fix could be to disable source mapping. We've taken care to rewrite this code to avoid nested event loops if source maps are not enabled. If that does not solve your issue, let me know how I can help you further.

Hope that helps!

Comment 17

[Mike Conley (:mconley) (:⚙️)]

Hey Jovan,

Does disabling source-mapping[1] seem to resolve the performance issue?

[1]: I believe that's done by entering the Debugger, going to the gear in the top right of the Debugger pane (not the gear at the top of the toolbox), and unselecting "Show Original Sources" in the popup that appears.

Comment 18

[Jovan Gerodetti]

I will try to test it when I encounter this issue again. At the moment I barely hit this problem anymore, but it still happens sometimes. 

I have to mention that I'm using source-maps so I can disable it for testing purposes, but I'm relying on this feature.

Comment 19

[Abe - QA (:Abe_LV)]

Jovan, Are you still getting the same issue after implementing the above suggestion, comment 17 ? Thanks

Comment 20

[Abe - QA (:Abe_LV)]

Closing this as incomplete due to inactivity and lack of response from the reporter.
If anyone can still reproduce it on latest versions, feel free to reopen the bug and provide more information. Thanks

Comment 21

[Jovan Gerodetti]

I can't reproduce the issue anymore.

Comment 22

[Firefox Bug Husbandry Bot]

Moving from Core::Untriaged to Core::General https://bugzilla.mozilla.org/show_bug.cgi?id=1407598