1137836 - When debugging angular.js: very slow stepping; missed breakpoints; crash leaving debugger

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect)

Description

[Jeff Griffiths (:canuckistani) (:⚡︎)]

Stackoverflow post: http://stackoverflow.com/questions/28039342/annoying-behaviour-of-firefox-developer-edition-crashes-a-lot-while-debugging?noredirect=1#comment45681034_28039342

"I am using Firefox regular edition since years and have very seamless experience while browsing and debugging apps. Few months back firefox launched its developer edition, so I switched to FF developer edition. But what I experieced is that, it crashes a lot while debugging JS (angularjs and jquery code) and some times the debugger does not hit at all even though that line of codes are being executed. This is really an annoying behaviour of firefox developer edition. Why it is so unstable even though I haven't installed any addons at all. Is Firefox Developer Edition is unstable or it is something related to my system. Is there any solution to solve this issue?"

Crash report: https://crash-stats.mozilla.com/report/index/2cec1a4b-183b-4541-ad3f-6345a2150217

Comment 1

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

The crash appears to be in JS engine.

Comment 2

[Jim Blandy :jimb]

I've asked on SO for reproduction instructions. I don't think we have enough information to fix this.

Looking at the stacks in the crash reports (and there are about eight of them that are all similar), the call |frame.script()| here is asserting:

http://hg.mozilla.org/releases/mozilla-aurora/annotate/3d8ee2772089/js/src/vm/Debugger.cpp#l3043

That frame is taken from an iteration over the debugger's Debugger.Frame table, which should only contain AbstractFramePtrs referring to live, scripted stack frames. The call to |frame.script()| should never have any reason to assert.

Unfortunately, the youngest frame in the stack trace seems to be bogus, so we can't see exactly which assertion is triggering.

I don't think we can do anything with this without means to reproduce.

Comment 3

[Jim Blandy :jimb]

Saurabh, I gather from your comments that the crashes occur when you have some breakpoints set, and are using f8 (continue) to let the code run until the next hit. However, the crash occurs in a call to a function that disconnects a debugger from the web page.

Is there any navigation that occurs just before the crash?

Comment 4

[Jim Blandy :jimb]

Nick, it seems like the only call to Debugger.prototype.removeAllDebuggees is here:

https://hg.mozilla.org/mozilla-central/file/2209a8de5d23/toolkit/devtools/server/actors/script.js#l584

I am no longer familiar with the server at all; do you know under which circumstances the ThreadActor is disconnected? The OP's stack trace has it happening in response to an observer notification.

Comment 5

[Saurabh]

Hey Hi Jim,
Sorry for late response. I've created a screen cast for showing the issue. 
Hope it will help and sorry for my bad English.
Uploaded the video on google drive, use following link to download:

https://drive.google.com/file/d/0BzTCaWndkZITSXNaUHRIZDR1NWs/view?usp=sharing

While debugging this app during above mentioned screen cast, I noticed that the debugger was not at all working correctly in both regular firefox and developer edition. While at the end of debugging in developer edition the browser crashed while there is no crash problem in normal edition. Still both the browsers are very less responsive and not hit all the breakpoints, whereas when I bebug it in chrome everything just worked fine with very seamless debugging.

For js framework I am using Angularjs. The code which is being executed during screen cast is angular js with some jquery code inline.

Please let me know if you require extra assistance.

Following is the crash report of the crash happened in developer edition during screen cast:
https://crash-stats.mozilla.com/report/index/6eaf48da-9006-4063-9334-308db2150301

Below is my system's configuration:
Manufacturer: HP
Model: HP-15 Notebook PC R007-tx
Processor: Intel(R)Core(TM) i5-4210U CPU, clock frequency: 1.70GHz
RAM: DDR3 8GB (4+4)(Frequency : 1600MHz)
GPU1- intel(R) HD Graphics Family
GPU2- NVIDIA GeForce 820M
HDD: 1TB (5400RPM)
OS: Windows 8.1Pro 64bit,

Comment 6

[Saurabh]

Also in normal case I never apply this much debugger, this one is for demo only cause I don't know where exactly the issue raises. Also during test I noticed that when there are so many debuggers firefox (both editions) responses very slowly.

Comment 7

[Jan de Mooij [:jandem]]

Clearing needinfo as this seems debugger-related and devtools people are on it.

Jim/Shu/Nick: maybe we can give the reporter a debug build and see if any assertion failures show up?

Comment 8

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

(In reply to Jim Blandy :jimb from comment #4)
> Nick, it seems like the only call to Debugger.prototype.removeAllDebuggees
> is here:
> 
> https://hg.mozilla.org/mozilla-central/file/2209a8de5d23/toolkit/devtools/
> server/actors/script.js#l584
> 
> I am no longer familiar with the server at all; do you know under which
> circumstances the ThreadActor is disconnected? The OP's stack trace has it
> happening in response to an observer notification.

ThreadActor.prototype.clearDebuggees is called on tab navigation and on detach, to remove the old globals so they are no longer debuggees.

Comment 9

[Jim Blandy :jimb]

(In reply to Saurabh from comment #5)
> Sorry for late response. I've created a screen cast for showing the issue. 
> Hope it will help and sorry for my bad English.

This is great; thank you very much! It is very clear.

I see four separate problems being described here:

- The navigation (say, when you first log in) is extremely slow with the debugger enabled.

- Continuing to the next breakpoint is extremely slow. There's no reason, under our model, that this shouldn't be perfectly fast, so this is definitely a bug.

- We miss breakpoints. Obviously a bug.

- We crash. I was hoping this was bug 1125120, which is fixed, but it seems that your latest crash is indeed based on 38.0a2, which does include changeset 58222952d073, in which that bug was fixed. So we have another removeDebuggeeGlobals crash to find and fix.

What I'm aiming for is to be able to reproduce these problems on my own machine. Once we can make each of these problems reproducible within Mozilla, then it is much more likely we can fix them promptly. Right now, all I can do is try things that I think resemble what you're doing, and hope the problem happens to me too. If I happen not to do the wrong thing, then I won't see the problem.

Is the code you're working on public, by any chance? If so, we can try to do exactly what you've done.

Finally, could you download this nightly build of Firefox, which has additional debugging checks enabled, and go through the steps you show in your video, and see if it crashes?

http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win64-debug/1425328944/firefox-39.0a1.en-US.win64.installer.exe

If you can run it from the command line, it may print out interesting things before it crashes there. Also, the checks may cause it to crash earlier, and thus closer to when the actual problem occurs.

Thanks very much for helping us out with this.

Comment 10

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

(See comment 9)

Comment 11

[Jim Blandy :jimb]

Saurabh, the nightly build that I suggested you try in comment 9 will probably run more slowly than a release Firefox, because it is doing the extra checks. So you should only use it for trying out the steps in your video.

I doubt it will fix the slowness, but it may fix the crash. If so, you can run a nightly build to get the crash fix without the slow checks: https://nightly.mozilla.org/

Comment 12

[Jim Blandy :jimb]

Shu-yu Guo tells me that that nightly contains the fix for bug 1136397 (not accessible to the general public), which is what might fix your crash.

Comment 13

[Shu-yu Guo [:shu]]

(In reply to Saurabh from comment #5)
> Hey Hi Jim,
> Sorry for late response. I've created a screen cast for showing the issue. 
> Hope it will help and sorry for my bad English.
> Uploaded the video on google drive, use following link to download:

Is it possible to make this app available to us for debugging purposes?

Comment 14

[Saurabh]

(In reply to Jim Blandy :jimb from comment #9)
> (In reply to Saurabh from comment #5)
> > Sorry for late response. I've created a screen cast for showing the issue. 
> > Hope it will help and sorry for my bad English.
> 
> This is great; thank you very much! It is very clear.
> 
> I see four separate problems being described here:
> 
> - The navigation (say, when you first log in) is extremely slow with the
> debugger enabled.
> 
> - Continuing to the next breakpoint is extremely slow. There's no reason,
> under our model, that this shouldn't be perfectly fast, so this is
> definitely a bug.
> 
> - We miss breakpoints. Obviously a bug.
> 
> - We crash. I was hoping this was bug 1125120, which is fixed, but it seems
> that your latest crash is indeed based on 38.0a2, which does include
> changeset 58222952d073, in which that bug was fixed. So we have another
> removeDebuggeeGlobals crash to find and fix.
> 
> What I'm aiming for is to be able to reproduce these problems on my own
> machine. Once we can make each of these problems reproducible within
> Mozilla, then it is much more likely we can fix them promptly. Right now,
> all I can do is try things that I think resemble what you're doing, and hope
> the problem happens to me too. If I happen not to do the wrong thing, then I
> won't see the problem.
> 
> Is the code you're working on public, by any chance? If so, we can try to do
> exactly what you've done.
> 
> Finally, could you download this nightly build of Firefox, which has
> additional debugging checks enabled, and go through the steps you show in
> your video, and see if it crashes?
> 
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-
> central-win64-debug/1425328944/firefox-39.0a1.en-US.win64.installer.exe
> 
> If you can run it from the command line, it may print out interesting things
> before it crashes there. Also, the checks may cause it to crash earlier, and
> thus closer to when the actual problem occurs.
> 
> Thanks very much for helping us out with this.

I can give you access to my app 14 March(IST) onwards so that you can debug it, till then I will try the nightly build.

Comment 15

[Logan Smyth [:loganfsmyth]]

Given the age of this, I'm going to close.