Closed Bug 1215187 Opened 10 years ago Closed 9 years ago

Silverlight hang and plugin crash ~15times a days since version Firefox 41. Firefox 40 do not have the problem

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Version:
41 Branch
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(firefox41 affected)

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox41 --- affected

People

(Reporter: denis.verreault, Unassigned)

References

Details

(Keywords: crash, crashreportid, regressionwindow-wanted)

Crash Data

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36 Steps to reproduce: Navigating on websites that uses Silverlight. Exemple : https://dev.medfarsolutions.com, NetFlix 8 hours of continuous utilisation. Firefox v40.0.3 never crashed like this in 3 weeks. Since version 41.0.1 it starts hanging/crashing a lot. I can rollback to v40 to fix the issue but I have 2200 clients running on auto updates. Actual results: 15 crashes : Silverlight Plug-In may be busy, or may have stopped responding. You can stop the plugin now, or you can continue to see if the plugin will complete. Plugin never recovers and all sessions crash Expected results: No crash =)
Severity: normal → critical
Priority: -- → P1
If FF crashed, could you type about:crashes and provide some crash reports (bp-...).
Component: Untriaged → Plug-ins
Flags: needinfo?(denis.verreault)
Priority: P1 → --
Product: Firefox → Core
Ok. I'll need a few minutes. I'll be back with the report
Flags: needinfo?(denis.verreault)
I have some additional crash reports to add. A lot of my users as well as co-workers are experiencing the same problem but were unable to coherently write repro steps to file a ticket. I have personally reverted back to 40.3 for testing and had no issues for two days in a row. Updated back to current and the crashes began again. Device 1 was updated from 40.3 to 41.0.1 late on the 12th or early on the 13th. From 1 device https://crash-stats.mozilla.com/report/index/bp-dce412e4-2a04-4f07-914e-8863b2151016 https://crash-stats.mozilla.com/report/index/bp-098fe315-9f60-4929-834f-5802e2151015 https://crash-stats.mozilla.com/report/index/bp-eabba1a3-0f7b-4897-a4fd-4ec072151014 https://crash-stats.mozilla.com/report/index/bp-fbef40ba-ace3-4710-a2fb-6bfd62151014 https://crash-stats.mozilla.com/report/index/bp-253b25e2-a24e-4395-9b94-250dc2151013 Device 2 has been used for troubleshooting by upgrading or downgrading versions. From 2nd device https://crash-stats.mozilla.com/report/index/bp-79ac7764-c8ee-4eae-8675-183272151016 v41.0.1 https://crash-stats.mozilla.com/report/index/bp-f6600760-3118-4fbf-b6cd-0d57b2151008 v42.0b4 https://crash-stats.mozilla.com/report/index/bp-d6f34cce-2967-421f-a308-7b7d72151008 v42.0b4 https://crash-stats.mozilla.com/report/index/bp-cc27cd9d-7517-4344-87cd-02b542151016 v42.0b4 https://crash-stats.mozilla.com/report/index/cc27cd9d-7517-4344-87cd-02b542151016 v42.0b4 https://crash-stats.mozilla.com/report/index/d96fa772-140b-4396-99f3-76d052151016 v42.0b4 https://crash-stats.mozilla.com/report/index/f61e3383-c015-453b-8ab5-95df42151016 v42.0b4 https://crash-stats.mozilla.com/report/index/eb88c1dc-ba2a-4709-bbeb-eabf62151016 v42.0b4 https://crash-stats.mozilla.com/report/index/ee164310-6f32-4f07-a051-2891a2151007 v41.0.1 https://crash-stats.mozilla.com/report/index/bp-b1eff658-c18e-4560-8eea-dbb7b2151016 v41.0.1 https://crash-stats.mozilla.com/report/index/00ca64ee-143d-4f73-9480-fe0442151016 v41.0.1
Do you have a testcase (like URL) where the crash is almost instant? If not, I think you can install the tool Mozregression to find a regression range. See http://mozilla.github.io/mozregression/ for details (use the command-line version). Run the command "mozregression --bits=32 --good-release=40" and paste the pushlog (from mozilla-inbound) given in the console output.
Flags: needinfo?(denis.verreault)
Keywords: regressionwindow-wanted
Flags: needinfo?(aradia4)
These guys seems to have the same problem : https://www.kb.blackbaud.com/articles/Article/96256
Flags: needinfo?(denis.verreault)
Testcase 1: 1. Open "https://dev.medfarsolutions.com/" in 6 different tabs (1 tab may reproduce the problem but it would take much longer) 2. User "qwe" pass "qwe", which is an invalid user 3. press enter 6 times quickly, change tab, press enter to login 6 times quickly, change tabs and repeat. Should crash within 20 to 30 seconds
*3. The mouse focus on the password box must be set first for the "enter" to trigger a login.
If it doesnt crash, keep opening tabs and login on others while the silverlight xap is loading... guaranteed success =)
I know its a longshot but could this bugfix be Related to the issue? --> https://bugzilla.mozilla.org/show_bug.cgi?id=1165981
Same exact issue here. I guess a bunch of our machines updated over the weekend because our users are putting in a ton of helpdesk tickets about Firefox 41.0.1 and 41.0.2 crashing when using Silverlight (and Flash Player to a lesser extent). Most are Windows 7 x64 Enterprise.
Also: we noticed that if users right-clicked on a Flash animation, Firefox would sometimes lock up. We did not notice the same behavior with Silverlight, even though it looks like Silverlight is producing the majority of the crashes. We see this a lot because our internal ERP runs primarily on Silverlight. That's probably why home users are not seeing this as much, because less of the public web is using Silverlight now.
I suspect that this is a dup of bug 1209464.
Just read that bug. Could be a duplicate. This is pretty serious for us. We've seen enough crashes and hangs lately that we've got to recommend Internet Explorer over Firefox for now, which I hate doing. Our ERP is 95% based on Silverlight, and that won't be changing any time soon. That's why, I'm guessing, the general public doesn't see this as much, as Silverlight is only a fraction of web traffic. For us, this bug is truly a showstopper because it's making it where employees truly cannot get their work done in Firefox.
I've been attempting to do the regression to identify which nightly build the problem was introduced in. The problem I am running into (It might be an education thing) is I don't have time to do it all in one sitting, resulting in me having to start over instead of picking up where I was last. Is there a way to identify which nightly build is running and start mozregression from that point?
Flags: needinfo?(aradia4) → needinfo?(epinal99-bugzilla2)
If FF40 worked fine, just run "mozregression --good-release=40". Honestly, mozregression uses dichotomy, so it's pretty fast, especially if you're able to reproduce the bug/crash quickly.
Flags: needinfo?(epinal99-bugzilla2)
(In reply to Kalvin from comment #17) > Is there a way to identify which nightly build is running and start mozregression > from that point? If you watching what builds are being run during the bisection, you can run mozregression again with the --good and --bad dates adjusted from what you've seen so far.
Just to clarify: I was reading Bug 1209464, and assuming that bug is causing the issue listed in this bug, is it really not going to be fixed until Firefox 44? Am I misreading that? If so, good luck. By that point, Firefox will be a distant memory for us because we can't go that long with this broken. It's a complete and utter disaster for us, and if this really is not going to be fixed in the next couple of weeks, I'm truly astounded.
Target milestone refers to when the fix landed on mozilla-central, the primary development repo. Currently, that corresponds to Firefox 44. However, it was also uplifted for Firefox 42 and 43 in comments 26/27. The status-firefox42 and status-firefox43 flags are set to "fixed" to indicate that. It would be great if you could download a current beta build and verify proper behavior because it *should* contain the fix. And for the record, Firefox 42 is due for final release on November 3.
@Ryan VanderMeulen [:RyanVM UTC-4] 2015-10-22 18:44:22 PDT Thx. I know this impact a lot of business but I fully understand that this is the stuff that will happend no matter what. We will do our best to determine the version that introduced the bug using mozregression. It seems like the problem is harder to reproduce using the regression tool tho. I'm still working on identifying the version where the bug was introduced. Best of lucks! Have a good night Denis Verreault
@Ryan VanderMeulen [:RyanVM UTC-4] 2015-10-22 18:44:22 PDT Thx. I know this impact a lot of business but I fully understand that this is the stuff that will happend no matter what. We will do our best to determine the version that introduced the bug using mozregression. It seems like the problem is harder to reproduce using the regression tool tho. I'm still working on identifying the version where the bug was introduced. Best of lucks! Have a good night Denis Verreault
Denis, based on some of the comments in this bug, you might want to try out a recent beta of Firefox 42 as well (42b9 should be out later today). It's had a variety of different plugin fixes land on it and I'd hate for you to go through the trouble of tracking down the regression range only for it to already be fixed.
Flags: needinfo?(denis.verreault)
Ok. I'll take a look at version 42 and deploy it for a few Clients. Is there an estimated date for the official release of v42?
Flags: needinfo?(denis.verreault)
this coming Tuesday
Any updates, Denis? :)
Flags: needinfo?(denis.verreault)
Hi! Thx for the reminder. We rolled back all clients to firefox v40 for now. We don't get as many feedback as before, only our internal tests. V42 seems better then v41. The frequency of the crashes has been reduced significantly but its still not as good as v40. ~3 crash a day for v42 I've seen the news about firefox removing support for silverlight next year so we are removing Silverlight gradually too. We should be done by next year and I think we'll just keep our clients on v40 until then. Thank you! Denis Verreault
Flags: needinfo?(denis.verreault)
Denis, thanks again for the quick reply. I appreciate your willingness to keep working with us on this issue, as frustrating as I know this can be for you and your clients. I understand where you're coming from, but leaving users on a known-insecure version of Firefox in the mean time is a bit of a scary prospect. From our standpoint, we'd love more information to continue trying to track down the problem so that your clients can remain on a fully supported version instead. Can you please provide links to the recent crash reports from the Fx42 final release for our engineers to look at? Also, I think a mozregression run to try tracking down the cause would be helpful to shed more light on what made this spike on Fx41 in the first place. If you're able to easily reproduce the crashes, a command like |mozregression --good-release 40 --bad-release 41| should be able to bisect down to a cause in a fairly short amount of time if you're willing to give it a try. http://mozilla.github.io/mozregression/
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(denis.verreault)
I spent a few hours trying to do the regression without success. It seems like the behavior on mozregression isnt exactly the same and wouldnt crash as much... I know its weird... I'll send the crash report for v42 soon. See you later! Denis
Flags: needinfo?(denis.verreault)
It's not that crazy since mozregression uses nightly builds, which can have different features enabled/disabled vs. what actually shipped to users in the final release. Thanks for trying at least :)
Hi Denis, just wondering if you had any recent Fx42 crash reports you can send our way :)
Flags: needinfo?(denis.verreault)
Hi Ryan! I did not forget you. Were there multiple versions of Fx42 deployed? Because I don't have seem to have as many crashes as before. My team still get a few crash calls once in a while but not that many. I'll pass the directive to get the crash reports directly from the clients since thoses are getting a little rare theses days. Thx for the follow up! Denis
Flags: needinfo?(denis.verreault)
At this point, the only Firefox 42 bugfix releases have been on Android. Glad to hear things are working better!
See Also: → 984668
Denis, just wanted to check in with you to hear if Fx43 is working OK for you at this point. If so, I think we can go ahead and resolve this bug as worksforme?
Flags: needinfo?(denis.verreault)
Hi Ryan, Thanks a lot for your concern, it is really appreciated. Happy new year btw! ;) We havent transfered many clients on v43 yet since there is a problem with Radpdf that blocks one of main features. I asked a collegue to post the bug : https://bugzilla.mozilla.org/show_bug.cgi?id=1237979 We are still trying to figure out a way around it with a modification on our side but it really looks like a deadend at the moment. Since most clients are still on v42, I dont have much information on the current issue versus firefox v43 Have a good day! Denis Verreault
Flags: needinfo?(denis.verreault)
Denis, given the lack of screaming, I assume this is gone now?
Flags: needinfo?(denis.verreault)
Yes. Version 44 seems much more stable then 41 was. Thx a lot for the help! ;) Denis Verreault
Flags: needinfo?(denis.verreault)
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.