Closed Bug 1240881 Opened 4 years ago Closed 4 years ago

[e10s] console hangs when debugging and reloading a few times


(DevTools :: Console, defect, P1)

46 Branch


(e10s+, firefox47 fixed, firefox48 fixed)

Firefox 48
Tracking Status
e10s + ---
firefox47 --- fixed
firefox48 --- fixed


(Reporter: Vineg, Assigned: bgrins, NeedInfo)


(Blocks 1 open bug)


(Whiteboard: [btpp-fix-now])


(2 files)

User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.107 Safari/537.36

Steps to reproduce:

Open web console (ctrl+shift+I), open debugger tab, place a breakpoint anywhere in JS code, reload page so script execution paused on breakpoint, type 1+1 in console, press enter

Actual results:

no output in console. if I reload page, web console still not responsive to user input

Expected results:

expected console output "2".
Component: Untriaged → Developer Tools: Console
I can't reproducie it in FF46 on Win 7 with e10s on/off.

Could you test with a fresh profile, please:
Flags: needinfo?(Vineg)
edit: when paused in debugger reload the page few times(ctrl+R), debugger still paused. Console hangs almost every time, some times it starts working after pressing F8 to resume script execution.

I tested with fresh profile on
Flags: needinfo?(Vineg)
Ok, I'm able to reproduce it with e10s enabled. The crucial step is reloading the page a few times before using the console.

It works normally with e10s disabled.
Blocks: e10s
Ever confirmed: true
Summary: console hangs when debugging → [e10s] console hangs when debugging and reloading a few times
Jeff, just wanted to flag this for the devtools team, sounds bad
Blocks: dte10s
tracking-e10s: --- → +
Flags: needinfo?(jgriffiths)
Jeff is out, over to :bgrins for triage.
Flags: needinfo?(bgrinstead)
Flags: needinfo?(jgriffiths)
Seeing this error:

error occurred while processing 'autocomplete: Error: Debugger.Frame is not live
Stack: WCA_onAutocomplete@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/webconsole.js:935:9
DSC_onPacket@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/main.js:1643:15
ChildDebuggerTransport.prototype.receiveMessage@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/transport/transport.js:742:5
EventLoop.prototype.enter@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/script.js:349:5
ThreadActor.prototype._pushThreadPause@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/script.js:543:5
ThreadActor.prototype._pauseAndRespond@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/script.js:752:7
BreakpointActor<.hit@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/breakpoint.js:153:12
Test case:

Open page
Open debugger and set breakpoint on line 3 of the html page
Reload page twice
Evaluate 1+1 in console

console outputs 2

console doesn't output anything
Better stack trace:

"onPacket threw an exception: Error: Server did not specify an actor, dropping packet: {"error":"unknownError","message":"error occurred while processing 'autocomplete: Error: Debugger.Frame is not live\nStack: WCA_onAutocomplete@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/webconsole.js:935:9\nDSC_onPacket@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/main.js:1643:15\nChildDebuggerTransport.prototype.receiveMessage@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/transport/transport.js:742:5\nEventLoop.prototype.enter@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/script.js:349:5\nThreadActor.prototype._pushThreadPause@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/script.js:543:5\nThreadActor.prototype._pauseAndRespond@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/script.js:752:7\nBreakpointActor<.hit@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/breakpoint.js:153:12\n@http://localhost/testapp/breakpoint.html:3:5\nLine: 935, column: 9"}
Stack: DebuggerClient.prototype.onPacket@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/client/main.js:939:9
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
DevToolsUtils.executeSoon*executeSoon@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/DevToolsUtils.js:34:11
LocalDebuggerTransport.prototype.send@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/transport/transport.js:562:7
DSC_send@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/main.js:1391:5
ChildDebuggerTransport.prototype.receiveMessage@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/transport/transport.js:742:5
Line: 939, column: 9"
Also bad: once this happens and then you close the toolbox, you are unable to reopen it
cc;ing Bryan and adding P1.
Priority: -- → P1
So.. I've even been able to get breakpoints to fail on this test page in e10s and also have the source occasionally not show up - I filed Bug 1246299 for that.  I'm not sure if it's strictly blocking but tagging it so we can track that work.

It seems the webconsole is getting confused with what frameActor is active, so that needs to be fixed.  I think we could make this fail more gracefully relatively easily so that could be a first step.
Blocks: 1246299
Flags: needinfo?(bgrinstead)
More graceful failure at least if we get in this bad case.  This allows the tools to still function if this case is hit (and the toolbox can close/reopen successfully)
Assignee: nobody → bgrinstead
Comment on attachment 8716514 [details] [diff] [review]

See comment 12
Attachment #8716514 - Flags: review?(jlong)
See Also: → 1121038
Comment on attachment 8716514 [details] [diff] [review]

Review of attachment 8716514 [details] [diff] [review]:

How come you remove the `if(frameActor)`? You just want it to be caught in the exception handler now?

Looks fine to me
Attachment #8716514 - Flags: review?(jlong) → review+
Blocks: 1254613
Whiteboard: [btpp-fix-now]
(In reply to James Long (:jlongster) from comment #14)
> How come you remove the `if(frameActor)`? You just want it to be caught in
> the exception handler now?

Yeah, if there's a frameActorId but no associated frameActor I think that's also an exceptional case
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 48
Brian, we might roll e10s out to a subset of users in 47. Would you like to uplift this?
Flags: needinfo?(bgrinstead)
(In reply to Jim Mathies [:jimm] from comment #19)
> Brian, we might roll e10s out to a subset of users in 47. Would you like to
> uplift this?

Yeah this should be safe to uplift, I'll create a request
Flags: needinfo?(bgrinstead)
Comment on attachment 8716514 [details] [diff] [review]

Approval Request Comment
[Feature/regressing bug #]: e10s (no particular regressing bug, the debugger / webconsole seem to have always had this problem in e10s)
[User impact if declined]: In e10s, the web console becomes unusable when reloading a page multiple times with a breakpoint that gets hit during load.  Then when you close the toolbox, you aren't able to re-open it.  Note that this patch doesn't fully fix the problem, it's just making the failure less bad.  Trying to evaluate scripts while paused in this condition will still fail, but it will begin working again when continuing.  And the toolbox can be closed and re-opened with no problems.
[Describe test coverage new/current, TreeHerder]: none
[Risks and why]: The patch itself is adding a try/catch in a place that shouldn't throw an exception, so it's pretty low risk.  Again, it's not a full fix for the problem though, it's just making things less bad.
Attachment #8716514 - Flags: approval-mozilla-beta?
Hello Vineg, could you please verify this issue is fixed as expected on a latest Nightly build? Thanks!
Flags: needinfo?(Vineg)
Comment on attachment 8716514 [details] [diff] [review]

Minimizing the likelihood in which webconsole becomes unusable in e10s. Beta47+
Attachment #8716514 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
QA Whiteboard: [good first verify]
I have reproduced this bug with Firefox nightly 46.0a1(build id:20160119030232)on
windows 7(64 bit)

I have verified this bug as fixed with Firefox beta 48.0b3(build id:20160623122823)
User Agent:Mozilla/5.0 (Windows NT 6.1; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.