1244785 - Unresponsive UI & crash in [@ shutdownhang | WaitForSingleObjectEx | WaitForSingleObject | PR_Wait | nsThread::ProcessNextEvent | NS_ProcessNextEvent | mozilla::jsinspector::nsJSInspector::EnterNestedEventLoop ]

Status: RESOLVED WONTFIX

(DevTools :: Debugger, defect, P1)

Description

[raphael777777]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20160123151951

Steps to reproduce:

While FF is idle on my computer with 1 window and 1 tab open, the CPU usage for FF constantly spikes up to 13%. 


Actual results:

When this happens, the User Interface becomes unresponsive. This means that nothing in the viewport works except the scroll wheel, and if I click the reload button it will spin indefinitely and FF will crash. I have submitted hundreds of crash reports due to this issue. Here are some of them:

https://crash-stats.mozilla.com/report/index/bp-894f9c08-81b7-49ab-821b-cf25f2160120 https://crash-stats.mozilla.com/report/index/bp-d3ada675-6108-4c7d-8174-b9e142160119 
https://crash-stats.mozilla.com/report/index/bp-593181bc-f270-44fe-87c2-9f3162160118 
https://crash-stats.mozilla.com/report/index/bp-e882d003-0831-4836-867f-9088f2160118
https://crash-stats.mozilla.com/report/index/bp-05d35c41-07c4-4710-a96d-26c242160115 


Expected results:

I have attempted restarting Windows in safe mode, and while in Windows safe mode, starting FF in FF safe mode, and I get the exact same behavior of the CPU spikes and FF lagging/sluggishness/unresponsiveness. I have also tried it with Windows in normal start mode and FF in safe mode, but nothing changes. The constant laggyness and/or complete unresponsiveness is becoming unbearable.

I have tried creating new profiles, reinstalling FF, turning hardware acceleration on/off, and all the troubleshooting steps listed here:

https://support.mozilla.org/en-US/kb/websites-look-wrong-or-appear-differently

https://support.mozilla.org/en-US/kb/firefox-slow-how-make-it-faster

https://support.mozilla.org/en-US/kb/firefox-uses-too-many-cpu-resources-how-fix

https://support.mozilla.org/en-US/kb/firefox-hangs-or-not-responding

https://support.mozilla.org/kb/Firefox+is+already+running+but+is+not+responding

http://develop.alpdesigns.ch/pages/other/speed_firefox.html

http://codebetter.com/darrellnorton/2005/01/28/speeding-up-firefox-the-right-way/

And nothing has worked.

Comment 1

[raphael777777]

In addition, instead of the crash I described above, most of the time the UI will just be incredibly laggy/unresponsive/sluggish. I will mouseover things that should immediately popup and it takes 10-20 seconds before they popup, or I will type text in a form field and there will be delays of 10 seconds before my text shows up, or I will try to scroll the page by grabbing the scrollbar and moving the mouse and it will scroll maybe 100 pixels and pause for 10 seconds before it suddenly jumps to the point I scrolled to.

Comment 2

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

First, update your GPU drivers to the 361.75 version.
Second, try refreshing Firefox, so go to "about:support" and press "Refresh Firefox..." and try to produce the same effect or crash without installing any addons.
It's very odd that the same thing happen in safe mode, are you sure that you don't have any bad sector in system disc and your RAM is stable if you overclock. I would recommend look on SMART values and test your RAM with e.g. Memtest86.

Comment 3

[raphael777777]

My computer has a GeForce GTS 250. When I go to the Nvidia website it says the recommended driver version is 341.92. I was using 341.92 when the problems first started. I was posting with someone in one of the Mozilla forums regarding this issue to try anything that might fix it, and I had temporarily downgraded to 341.44 to see if it made a difference (it didn't). Is it safe to upgrade to 361.75 if the nvidia site recommends 341.92?

If I use the "refresh Firefox", does it affect all profiles or just the profile you're currently using? I ask because I didn't want to mess up one of my existing profiles in case the refresh doesn't work.

I will do the memory test and post the results here when it finishes. I have defragged and scanned the harddrive for errors and it shows none.

Comment 4

[raphael777777]

One correction to the note above - this computer has *2* PNY Verto GeForce GTS 250's that are *not* connected by SLI cables. Each card has 1GB of GDDR3 SDRAM.

Comment 5

[Paul Pasca[Away. Please needinfo? Paul Oiegas [:pauloiegasSV]]]

Hi Raphael,

The Socorro reports shows that this crash signature is still present on the last 7 days, but only on older builds. None of the crashes is on the latest release version 44.0.2. Can you please confirm that you no longer encounter this crash on the latest release 44.0.2? It will be helpful to know if this issue was fixed along the way.

Thanks,
Paul.

Comment 6

[raphael777777]

I have had no crashes since 2/11/16, which is consistent with the time period you gave (7 days). I am on FF 44.0.2. Thank you!!

Comment 7

[Paul Pasca[Away. Please needinfo? Paul Oiegas [:pauloiegasSV]]]

Based on Socorro reports from last 7 days and comment 6, I will mark the issue as RESOLVED WORKSFORME. If you still encounter this crash, feel free to reopen this issue.

Comment 8

[raphael777777]

I just had 2 more crashes today: 

https://crash-stats.mozilla.com/report/index/bp-3e94509f-6262-4939-9631-ce0a92160224
https://crash-stats.mozilla.com/report/index/bp-2f7fa8c2-f384-45c6-8d6e-39d0d2160224

Same behavior as before.

Comment 9

[Ryan VanderMeulen [:RyanVM]]

Moving to devtools based on the JSInspector stuff in the hang stack. Can you help find an owner, past?

Raphael, can you confirm whether you're using the browser's devtools or not?

Comment 10

[Panos Astithas (he/him) [:past] (please ni?)]

JSInspector is used by the JS debugger, so let's ask Eddy.

Comment 11

[Eddy Bruel [:ejpbruel]]

The JSInspector is used by the debugger to pause the debuggee, for instance when it hits a breakpoint. Because the debugger runs in the same thread as the debuggee, rather than actually pausing the latter, we have to create the illusion that it is paused, by spinning up a nested event loop (which is what the call to EnterNestedEventLoop does).

While we are inside this nested event loop, we don't want to process any events that could cause debuggee code to run. Doing so would break the illusion that the debuggee is paused. The way we currently do this is by explicitly suppressing things such as mouse and keyboard events. That could explain why your browser becomes unresponsive.

What I don't understand is how this call to EnterNestedEventLoop ends up being on the call stack. That should only be possible if the devtools are open. And even then, we should exit from that nested event loop when the debugger is closed.

Having some more concrete steps to reproduce would be a big help here. Otherwise I don't really know where to start.

Comment 12

[Eddy Bruel [:ejpbruel]]

Moving this to the debugger component based on the fact that it involves JSInspector.

Comment 13

[Eddy Bruel [:ejpbruel]]

Tentatively assigning P1 to this since it is a crasher. This bug won't be actionable until we have a way to reproduce/analyse the problem, though.

Comment 14

[raphael777777]

Ryan VanderMeulen, I use firebug instead of the built-in devtools.

Comment 15

[Eddy Bruel [:ejpbruel]]

Honza, does Firebug also use nested event loops to implement pausing? In that case, this looks like it might be a bug in Firebug.

Comment 16

[raphael777777]

Now sure if this is helpful, but here are 2 more crash reports from yesterday and today:

https://crash-stats.mozilla.com/report/index/bp-42df27d6-5ace-4ad0-ab56-cacfa2160225

https://crash-stats.mozilla.com/report/index/bp-04e45007-e1a1-45de-a435-15dbc2160226

Comment 17

[Jan Honza Odvarko [:Honza] (always need-info? me)]

(In reply to Eddy Bruel [:ejpbruel] from comment #15)
> Honza, does Firebug also use nested event loops to implement pausing? In
> that case, this looks like it might be a bug in Firebug.
Firebug doesn't use EnterNestedEventLoop directly, it's using the RDP
protocol to break/pause JS execution so, not sure if using RDP can
lead to a crash. Do we have STR?

Honza

Comment 18

[Eddy Bruel [:ejpbruel]]

Hi Raphael.

Since this bug is causing Firefox to crash, it's currently on top of our priority list for the debugger. However, there is not much we can do unless we know exactly what steps we should use to reproduce the bug. You did add some steps to reproduce, but they are not detailed enough (the fact that you are using Firebug is important information, for instance!).

Do you think you could help us out by giving us a more detailed list of steps to reproduce? Thanks!

Comment 19

[raphael777777]

Eddy,

I would love to help. However, the problem I have is the site I work on is on an internal website for my company and I have to be very careful about what I share with the outside. I can tell you that the pages the freezes happen on are mainly pages that have lots (dozens/hundreds) of event listeners. I want to help, but I'm not sure how I can do that while not sharing important company information. Please let me know what my options are. If it involves logging internal Firefox data, posting screenshots/videos, or something like that I'm sure it will be fine. Just let me know what you need and I'll see if I can do it.

I can also tell you that I uninstalled Firebug yesterday and the issue has not happened since. After I uninstalled Firebug I tried using the built-in dev tools, and the issue has not happened with them.

Thank you!

Comment 20

[Jan Honza Odvarko [:Honza] (always need-info? me)]

(In reply to raphael777777 from comment #19)
> I can also tell you that I uninstalled Firebug yesterday and the issue has
> not happened since. After I uninstalled Firebug I tried using the built-in
> dev tools, and the issue has not happened with them.
Thanks for the update!

It looks like that Firebug is the culprit. But, Firefox must not crash
even if Firebug is incorrectly using the RDP protocol.
So, the bug is considered P1 for us.

> I would love to help. However, the problem I have is the site I work on is
> on an internal website for my company and I have to be very careful about
> what I share with the outside. I can tell you that the pages the freezes
> happen on are mainly pages that have lots (dozens/hundreds) of event
> listeners. I want to help, but I'm not sure how I can do that while not
> sharing important company information. Please let me know what my options
> are.

There are following options:
1) Share video screencast that shows what exactly you are doing in Firebug UI
2) Screen share with me (or Eddy) so, we can see what you are doing in Firebug UI

Would that work for you?

Some more questions:
* Does it happen if you disable the Script (js debugger) panel?
* Does it happen if you disable the Script, Net and the Console panels?

Honza

Comment 21

[raphael777777]

If I have the built-in devtools or the Firebug Script panel enabled these pages take many times longer (2 minutes+ vs. about 10 seconds with them disabled) to load than they do with the devtools/Firebug disabled. However, they didn't crash Firefox. But while they are loading the browser is completely frozen and I can't change tabs, scroll, etc.

I'm still working on creating a video to show the issues.

Comment 22

[Soledad Penades [:sole] [:spenades]]

Hello Raphael, I'm revisiting crashers and I found this one which has not had activity for a while. Now that Firebug has been discontinued, this is not a valid bug anymore, so I'm going to close this bug for now.

Feel free to reopen or file a different bug if you have issues with DevTools and we'll try to help you again :)

Thanks!