Closed Bug 753251 Opened 13 years ago Closed 11 years ago

crash in nsGfxScrollFrameInner::ScrollToImpl mainly with Silverlight 4

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Version:
13 Branch
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox13 + ---
firefox14 + wontfix
firefox15 + wontfix
firefox16 - affected

People

(Reporter: scoobidiver, Unassigned)

References

Details

(Keywords: crash, regression)

Crash Data

This bugs tracks the nsGfxScrollFrameInner::ScrollToImpl Mac signature that remains after the fix of bug 723190. It's #9 top crasher in 13.0b2 and #8 in 14.0a2 on Mac OS X. Signature nsGfxScrollFrameInner::ScrollToImpl More Reports Search UUID b7006dc1-147f-471f-b5aa-8f4692120502 Date Processed 2012-05-02 13:56:38 Uptime 150 Last Crash 2.5 minutes before submission Install Age 11.5 minutes since version was first installed. Install Time 2012-05-02 13:45:03 Product Firefox Version 15.0a1 Build ID 20120502030505 Release Channel nightly OS Mac OS X OS Version 10.5.8 9L31a Build Architecture x86 Build Architecture Info family 6 model 23 stepping 10 Crash Reason EXC_BAD_ACCESS / KERN_INVALID_ADDRESS Crash Address 0x568df396 App Notes AdapterVendorID: 0x10de, AdapterDeviceID: 0x 863 EMCheckCompatibility True Frame Module Signature Source 0 @0xb21b 1 XUL nsGfxScrollFrameInner::ScrollToImpl nsGfxScrollFrame.cpp:2034 2 XUL nsGfxScrollFrameInner::AsyncScrollCallback nsGfxScrollFrame.cpp:1676 3 XUL nsTimerImpl::Fire nsTimerImpl.cpp:508 4 XUL nsTimerEvent::Run nsTimerImpl.cpp:591 5 XUL nsThread::ProcessNextEvent nsThread.cpp:656 6 XUL NS_ProcessPendingEvents_P nsThreadUtils.cpp:195 7 XUL nsBaseAppShell::NativeEventCallback nsBaseAppShell.cpp:130 8 XUL nsAppShell::ProcessGeckoEvents nsAppShell.mm:441 9 CoreFoundation CFRunLoopRunSpecific More reports at: https://crash-stats.mozilla.com/report/list?signature=nsGfxScrollFrameInner%3A%3AScrollToImpl
It's not clear to me why we aren't re-opening bug 723190 - did the crash signature drop and only now surge again? CC'ing Josh.
It probably never totally went away, iirc we switched to a new bug to keep further patches and investigation on a clean slate. The patches in the last bug did greatly reduce the frequency of the crashes.
Crash Signature: [@ nsGfxScrollFrameInner::ScrollToImpl] → [@ nsGfxScrollFrameInner::ScrollToImpl ]
(In reply to Josh Aas (Mozilla Corporation) from comment #2) > It probably never totally went away, iirc we switched to a new bug to keep > further patches and investigation on a clean slate. The patches in the last > bug did greatly reduce the frequency of the crashes. Do you believe that this bug is caused by a new change to the product or new external software? If it's something we've done, are you the right person to investigate?
tracking-firefox13: ? → +
Assignee: nobody → joshmoz
(In reply to Alex Keybl [:akeybl] from comment #3) > Do you believe that this bug is caused by a new change to the product or new > external software? If it's something we've done, are you the right person to > investigate? It does seem to have come back on the map in Firefox 13. I'll take a look tomorrow.
The nature of the problem and, consequently, the stack trace, means this will be very hard to track down without repro steps. We're attempting to notify a deleted frame about scrolling (see the stack trace) but there is no indication of when that frame was deleted or why it didn't unregister for notification. This crash only happens in 32-bit mode and is the result of code used to support Quickdraw/Carbon plugins. We can resolve this crash by dropping support for Quickdraw/Carbon plugins, which we haven't done largely because they're still popular on Mac OS X 10.5 and we still support Mac OS X 10.5. Backing out 90268, which is our best guess as to what regressed this, isn't an option here. It's a huge patch and a lot has landed on top of it. It resolves more issues than it creates at this point, so we might have to just bite the bullet here until we get more info or drop Mac OS X 10.5 support.
Assignee: joshmoz → nobody
Spoke with Josh. This bug should only cause issues on 10.5 or 10.6/10.7 in 32-bit mode when users have QD/Carbon plugins, so we expect crashes to drop off longterm. That being said, it's still a top crasher prior to FF13's release. To have a bit more certainty with our understanding of this bug, I'd like QA to spend ~30min on trying to reproduce a crash in Flash video or Java Applets on Mac OS X 10.5, interacting normally with the plugins, closing tabs, and surfing to other pages intermittently. Outside of that, we don't have any leads to follow up on currently and may have to wontfix for FF13.
Keywords: qawanted
If someone is going to try to come up with repro steps, this bug happens when a Carbon/QD plugin instance is destroyed in very close proximity to a scrolling action. So closing a page with plugin instances on it one way or another while scrolling is probably your best bet.
Using one of the 10.5 lab machines, I spent some time trying to reproduce with no luck so far. I specifically tested with some of the URLs in the crash reports, trying scrolling, opening and closing sites with plugins, etc. I tested primarily sites with java and flash. I will make one more attempt on another machine.
No luck on the second 10.5 machine either using FF 13 B4- testing grooveshark site and hotmail sites which came up in crash stats.
I also try to make Firefox 13 beta 4 to crash using the hints from comment6 and comment7 but I couldn't. On you tube I've opened several videos in new tabs and except Firefox behaving very jerky, there were no crash when scrolling and closing tabs. Firefox didn't crash on Vimeo and also when playing several java games. The jerkyness is related to my test machine's configuration so I didn't bother with it.
Crash Signature: [@ nsGfxScrollFrameInner::ScrollToImpl ] → [@ nsGfxScrollFrameInner::ScrollToImpl ] [@ @0x0 | nsGfxScrollFrameInner::ScrollToImpl ]
QA testing so far has yielded no results. Are there any other leads we can follow for testing?
Vlad, can you have another go with the sites in comment 12?
Hi Anthony. I've performed exploratory testing using the sites from comment12 but I was unable to get a crash form Firefox 13 beta 5. Even if I closed all the sites in rapid succession, Firefox did not crash. As a conclusion, on my test machine at least, there is no crash.
Thanks Vlad. I'm not sure what else QA can do -- all our leads have dead-ended. Removing qawanted for now. Please re-add if there is something else we can try.
Keywords: qawanted
Seems to be crashing fairly reliably for me when I attempt to scroll on http://jalopnik.com/5916541/carroll-shelbys-dead-body-is-literally-in-limbo?utm_campaign=socialflow_jalopnik_facebook&utm_source=jalopnik_facebook&utm_medium=socialflow Once in a while it works without crashing, but most of the time it crashes. This is on OSX Lion on a current-model 15" macbook pro.
yeah, this is happening almost every time on gawker sites, possibly other sites as well. OSX Snow Leopard 10.6.8 using Firefox 13 and 14b6
I've spent about 30 minutes trying to reproduce this crash this morning (Mac 10.7, Firefox 14.0b6) using various Gawker pages. I've been unsuccessful so far. Josh Aas, we have a couple people on this bug who are able to reproduce this somewhat frequently. Is there any direction you can give them to get some debugging information so you can proceed with this bug?
Hello, This crash has occurred every time I view an article on Lifehacker.com, so I wanted to share my configuration with you if it helps you replicate the bug. This bug occurs on Fx 13.0.1 and Fx 14b; this bug did not occur on Fx12 or below to the best of my recollection. For your reference, the following crash reports were submitted: bp-c477d474-9ccf-455e-ba03-03ebd2120626 bp-1d34bd3b-0751-4b74-8672-bf1e92120626 bp-6aad66dc-ca4f-4678-b58c-bddd22120626 bp-b1e01c94-6b00-4d43-a0b1-010832120624 bp-6cbc7f54-f764-47ab-a080-e06952120624 bp-e258a25e-8935-41c3-b45c-1902f2120624 bp-a2670f72-a2d1-424f-94ec-e1c142120624 bp-7d961253-015c-40e8-99c6-6c5b42120624 bp-d0d15c86-ce95-45eb-aca9-4efe62120624 bp-e0a2357f-0eba-46ea-936a-b5d512120624 bp-6d293e3f-b33c-4e77-af62-43a412120624 bp-70887c7d-c9d0-4bf5-98f0-f20132120624 bp-c9f4a97c-2439-4d9d-88a8-976292120624 I am using a MacBook MC207LL/A with Mac OS X 10.6.8 "Snow Leopard"; the standard hard drive has been replaced with a Agility 3 SSD and the RAM has been increased to 8GB. Plugin-check reports that Quicktime, Silverlight, Flip4Mac, Java, Google Talk Video and ShockwaveFlash are up to date; it does not recognize iPhotoPhotocast, HP Home Client Plugin, SharePoint Browser Plug In, Microsoft Office Live Plug In, Juniper Networks Safari Extensions, WebEx64 General Plugin Container, Google Earth Plugin, Google Talk NPAPI Plugin. I have the following Add-ons installed, active and are current: Abduction!, Adblock Plus, BetterPrivacy, Easy YouTube Downloader, Element Hiding Helper for Adblock Plus, Facebook Blocker, Forecastfox and Xmarks. I have Test Pilot installed, but disabled. The problem occurs regardless of whether or not "Smooth scrolling" or "Auto scrolling" are selected. Additionally, Firefox is not starting in Safe Mode when I hold down the Shift key and click the icon. Please let me know if I can help you in any way; this has rendered Fx unusable for me.
Hi Varun, can you clarify a couple of things for me? 1) What do you mean when you say "Plug-in Check does not recognize" certain plugins? Are these plugins installed? It'd be extremely helpful if you could compile a list of your Addon versions from about:addons and your Plugin versions from about:plugins pages. 2) Does this crash happen when you run in Safe Mode? An alternative way to start in Safe Mode is to run from terminal: Firefox.app/Contents/MacOS/firefox -safe-mode
1) PluginCheck reports some plugins as "Unknown plugin" and gives one the option to "Research" rather saying "Update" or "Up to Date"; these are what I refer to as not recognized. I apologise if I was unclear. Addons: Abduction 3.0.14, Adblock Plus 2.0.3, Better Privacy 1.68, Easy YouTube Video Downloader 6.1, Element Hiding Helper 1.22, Facebook Blocker 1.4, ForecastFox 2.0.21, Omnibar 0.7.13.20120613, Test Pilot 1.2.1 (disabled), Xmarks 4.1.0 Plugins: ShockwaveFlash 11.3.300.257, Google Talk NPAPI Plugin 3.1.4.8140, Google Talk Plugin Video Accelerator 0.1.44.16, Java Applet Plug-in 13.8.0, Flip4Mac Windows Media Plugin 2.4.4.2, Google Earth Plugin 6.2, Silverlight Plugin 5.1.104110.0, WebEx64 General Plugin Container 1.0, Juniper Safari Extensions 19757 [sic], QuickTime Plugin 7.6.6, Microsoft Office Live Plugin 12.3.0, Sharepoint Browser Plugin 14.1.0, HP Home Client Plug In 1.0, iPhotoPhotocast 7.0. 2. Starting in Safe Mode and not choosing any of the boxes does NOT appear to trigger a crash. Since I assume the next question is going to be to eliminate the addons one by one, I have preemptively test-disabled the most popular one, Adblock, and after disabling Adblock, the crash appears to not take place. It appears to be some interaction between Adblock and Fx 13/14 that's causing the crash. A page that appears to consistently crash Fx when Adblock is enabled is http://lifehacker.com/5921048/how-can-i-sleep-through-the-night.
Scratch that. I restarted Adblock and Element Hiding Helper and the page listed doesn't appear to crash any longer. I'll reload it a couple of times and report back.
New crash: bp-74c4215a-493d-48b5-ad78-8def82120701 Occurs in Fx14b10. Did not reoccur at restart, unlike previously.
Josh - would access to the actual crash minidumps help here? We've exhausted our internal QA options for reproducing, so we need to change strategies. Alternatively, we can still take speculative fixes in FF15 on Beta for the next couple of weeks. Please let us know.
Assignee: nobody → joshmoz
I'm out of ideas here.
Assignee: joshmoz → nobody
Colleagues, I have tried to reproduce this bug in Fx10-12, using the exact same addons and plugins (including versions) as I have installed in Fx13-14. The crash does not occur at all under Fx12 on any Gawker website, whereas Fx13 and the latest 14beta crash every instance. That would suggest that something seems to have changed between Fx12 and Fx13. I'm happy to help run any test cases you would like.
Varun, can you please use the mozregression tool to track down a 24-hour regression range? http://harthur.github.com/mozregression/ The first Firefox 13 Nightly is 2012-02-01. The last Firefox 13 Nightly is 2012-03-13
Here are some URLs that are showing up in early 14.0.1 data: 12 http://www.microsoft.com/getsilverlight/get-started/install/default.aspx 7 http://www.microsoft.com/getsilverlight/Get-Started/Install/Default.aspx 5 http://www.microsoft.com/getsilverlight/handlers/getsilverlight.ashx 2 http://gawker.com/5926982/lettuce+defiling-burger-king-employee-tracked-down-by- 2 http://www.glwiz.com/ 2 https://www.therapysites.com/CMS/editPage.seam?cid=1164 1 https://www.facebook.com/ 1 https://blu165.mail.live.com/mail/EditMessageLight.aspx?ecui=false 1 http://sn114w.snt114.mail.live.com/default.aspx#!/mail/InboxLight.aspx A comment from one user: "I was rewriting the email I just reported. I should also tell you that when I'm writing an email in Firefox, I always get a message--a banner at the top of the email that says, "This page asks to use a plugin that can only run in 32-bit mode. At the end of the line, there is a highlight area like the one below, that says, "Restart in 32-bit mode." This started showing up about 1 year ago. I click on it, then Firefox disappears & returns. Now the banner keeps reappearing." Many of the other comments so far mention Netflix/Hotmail and getting the restart in 32 bit mode notification.
I've been unable to reproduce this so far using the top URLs in comment 28. I'm using Firefox 14.0.1 on OSX 10.7 with Silverlight 5.1.10411.0 and Flash 11.3.300.265. I've tried going through the Silverlight Install/Uninstall a few times and have been using Hotmail in conjunction with a couple of Silverlight demos. So far I've been unable to crash. Not sure if it matters, but here is my graphics section from about:support... Vendor ID: 0x10de Device ID: 0x 8a4 WebGL Renderer: NVIDIA Corporation -- NVIDIA GeForce 320M OpenGL Engine -- 2.1 NVIDIA-7.18.18 GPU Accelerated Windows: 1/1 OpenGL AzureBackend: quartz
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #27) > Varun, can you please use the mozregression tool to track down a 24-hour > regression range? > http://harthur.github.com/mozregression/ > > The first Firefox 13 Nightly is 2012-02-01. > The last Firefox 13 Nightly is 2012-03-13 Yep, this would be fantastic and would allow us to take action on this bug. Varun - let us know if we can be of any assistance with the use of mozregression. We're unable to reproduce internally, so this would be really helpful.
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20100101 Tried this on 10.7 with 15 beta 1, with no luck. I mainly followed the suggestions of Varun in comment 21 plus Marcia's urls and hotmail as suggested in comments. https://crash-stats.mozilla.com/report/list?signature=nsGfxScrollFrameInner%3A%3AScrollToImpl If I'm looking correctly, 15 beta seems the last version to be affected (129 crashes) which would confirm the expectations in comment 6.
(In reply to Virgil Dicu [:virgil] [QA] from comment #31) > If I'm looking correctly, 15 beta seems the last version to be affected Aurora 16 is still affected but at a lower volume, likely because Aurora and Beta populations differ.
Some percentage of users that are crashing in 14.0.1 have http://www.systemlookup.com/FF_Extensions/15-DivX_Plus_Web_Player_HTML5.html installed: nsGfxScrollFrameInner::ScrollToImpl|EXC_BAD_ACCESS / KERN_INVALID_ADDRESS (105 crashes) 10% (11/105) vs. 5% (134/2688) {23fcfd51-4958-4f00-80a3-ae97e717ed8b} This crash also manifests itself as a EXC_BAD_ACCESS / KERN_INVALID_ADDRESS as well as EXC_BAD_ACCESS / KERN_PROTECTION_FAILURE.
From what I know from debugging the divx plugin in the past, I would not be surprised if divx is causing a crash with this signature.
(In reply to Marcia Knous [:marcia] from comment #33) > Some percentage of users that are crashing in 14.0.1 have > http://www.systemlookup.com/FF_Extensions/15-DivX_Plus_Web_Player_HTML5.html > installed: Can we try reproducing with this installed? It wouldn't be a direct correlation, but would still point us in the right direction if we got STR. We may want to pull URLs again and look for pages that likely have divx-supported video files embedded.
QA Contact: mozillamarcia.knous
Some more correlations from Beta, for the KERN_PROTECTION FAILURE crash: nsGfxScrollFrameInner::ScrollToImpl|EXC_BAD_ACCESS / KERN_PROTECTION_FAILURE (22 crashes) 32% (7/22) vs. 4% (23/647) firefox@ghostery.com (Ghostery, https://addons.mozilla.org/addon/9609) 27% (6/22) vs. 3% (18/647) {19503e42-ca3c-4c27-b1e2-9cdb2170ee34} (FlashGot, https://addons.mozilla.org/addon/220) 23% (5/22) vs. 2% (15/647) {a0d7ccb3-214d-498b-b4aa-0e8fda9a7bf7} (WOT, https://addons.mozilla.org/addon/3456) 23% (5/22) vs. 2% (16/647) artur.dubovoy@gmail.com (Flash Video Downloader, https://addons.mozilla.org/addon/6584) 23% (5/22) vs. 3% (22/647) personas@christopher.beard (Personas, https://addons.mozilla.org/addon/10900) 9% (2/22) vs. 0% (2/647) zoteroquicklook@gmail.com 9% (2/22) vs. 0% (2/647) zot2bib@mackerron.com (Zot2Bib, https://addons.mozilla.org/addon/6692) 9% (2/22) vs. 0% (3/647) firefox-extension@shareaholic.com (Shareaholic for Firefox, https://addons.mozilla.org/addon/5457) 9% (2/22) vs. 2% (10/647) en-US@dictionaries.addons.mozilla.org (United States English Dictionary, https://addons.mozilla.org/addon/3497) 9% (2/22) vs. 2% (13/647) {195A3098-0BD5-4e90-AE22-BA1C540AFD1E} (Garmin Communicator, https://addons.mozilla.org/addon/10278) 9% (2/22) vs. 2% (14/647) adblockpopups@jessehakanen.net 82% (18/22) vs. 75% (485/647) testpilot@labs.mozilla.com (Mozilla Labs - Test Pilot, https://addons.mozilla.org/addon/13661)
Some of the crashes seem to have a correlation to Logitech: 6% (1/18) vs. 1% (11/2011) DeviceDetection@logitech.com Some of the 10.5 reports I looked at had the Logitech Control Center module. So that might be another lead I can follow.
(In reply to Marcia Knous [:marcia] from comment #38) > Some of the crashes seem to have a correlation to Logitech: > > 6% (1/18) vs. 1% (11/2011) DeviceDetection@logitech.com Well, that's a single one of the 18 counted there, I wouldn't trust that as any conclusive correlation.
With not much else to go on and the fact that many of the comments mention scrolling, it could be related. (In reply to Robert Kaiser (:kairo@mozilla.com) from comment #39) > (In reply to Marcia Knous [:marcia] from comment #38) > > Some of the crashes seem to have a correlation to Logitech: > > > > 6% (1/18) vs. 1% (11/2011) DeviceDetection@logitech.com > > > Well, that's a single one of the 18 counted there, I wouldn't trust that as > any conclusive correlation.
Using my mid 2009 Macbook Pro, I was able to reproduce the issue of consistently getting the 32 bit yellow info bar. This is something that comes up consistently in the comments and from user outreach. I was able to generate that info bar consistently (but not crash) following these steps: 1. Install an older version of Silverlight (4.0.x) from oldversions.com 2. In Get Info check box to set Firefox to start in 32 bit mode 3. Load Netflix, or Silverlight Showcase site 4. Get the "Restart in 32 bit mode info bar"
We sent 200-some emails out about this. So far, everyone has mentioned Hotmail. The new hotmail design relies heavily on Silverlight and it seems that just looking at emails (possibly scrolling) triggers this crash -- although some people have mentioned the 32-bit info bar.
Hmm, check that, maybe it's the old hotmail and not the new hotmail. Silverlight is used to generate slideshows of photos in hotmail, open attached MS office documents etc so those may be productive areas of investigation
When testing Hotmail, I tried scrolling, flipping prefs in my mail configuration, etc and so far have not generated a crash.
Even without Step 4, I am still getting the infobar to come up in Hotmail, but just no crash. I believe that having the older version of Silverlight may be one of the keys.
http://blogs.office.com/b/microsoft-outlook/archive/2012/08/03/upgrade-from-hotmail-to-outlook-com.aspx seems to have the steps to update to the new preview. Wondering if that is making a difference in the crashes. Juan mentioned he crashed the other day using Hotmail, but I don't know which signature he got - adding him to the cc.
The crash I saw was bp-dbd47286-7eeb-43a7-b8d1-de4e52120810 [@ nsRootPresContext::RequestUpdatePluginGeometry] which is associated to bug 781272
Several users we contacted had 4.x versions of Silverlight, and one of them reported that updating to the latest Silverlight version resolved the problem.
Several users upon updating have reported this fixes the issue. We should begin to consider blocking older (4.x) versions of Silverlight on Mac, as this is having a serious adverse affect on Firefox for Mac. This issue, the recent Netflix problem, etc.
(In reply to Tyler Downer [:Tyler] from comment #49) > Several users upon updating have reported this fixes the issue. We should > begin to consider blocking older (4.x) versions of Silverlight on Mac Sounds like a good idea. Please file a bug against the AMO product and Blocklisting component.
(In reply to Marcia Knous [:marcia] from comment #48) > Several users we contacted had 4.x versions of Silverlight, and one of them > reported that updating to the latest Silverlight version resolved the > problem. Marcia, I can confirm that this crash occurs without fail on any Gawker website (Gawker, Jezebel, Lifehacker) on 10.6.8 using the latest version of Silverlight. I have not been home in a few weeks, but intend to run moz-regression this weekend. For what it is worth - the crash happens only during scrolling (it'll load fine), and does not occur on the first tab after a restart; only on subsequent tabs does it crash. i.e.: if you have lifehacker.com/1 open and lifehacker.com/2 restore after a crash, scrolling the first doesn't cause a crash, scrolling the second does. It appears to happen more consistently if I scroll down by hitting space or page down than dragging with the mouse.
Varun, do you have the crash Id's and about:plugins?
Ah, I see them above (this bug is getting too long to follow) nvm.
Varun: Are you scrolling using the Trackpad, or a mouse? (In reply to Varun from comment #51) > (In reply to Marcia Knous [:marcia] from comment #48) > > Several users we contacted had 4.x versions of Silverlight, and one of them > > reported that updating to the latest Silverlight version resolved the > > problem. > > Marcia, I can confirm that this crash occurs without fail on any Gawker > website (Gawker, Jezebel, Lifehacker) on 10.6.8 using the latest version of > Silverlight. I have not been home in a few weeks, but intend to run > moz-regression this weekend. > > For what it is worth - the crash happens only during scrolling (it'll load > fine), and does not occur on the first tab after a restart; only on > subsequent tabs does it crash. i.e.: if you have lifehacker.com/1 open and > lifehacker.com/2 restore after a crash, scrolling the first doesn't cause a > crash, scrolling the second does. It appears to happen more consistently if > I scroll down by hitting space or page down than dragging with the mouse.
Dragging the scrollbar (either mouse or trackpad) does not appear to trigger the crash. Scrolling by tapping space does. I remember checking if smooth scrolling made a difference, and it did not seem to, but I'll recheck with the latest Fx beta I have installed now.
I've been unable to reproduce this with Silverlight 5.1. If someone can provide me with a link to a Silverlight 4 for Mac download I'm willing to confirm this was "fixed" with Silverlight 5. Searching oldversions.com and google did not return any usable links for me.
I think there are actually two different crashes that are associated with this signature - the one that pertains to Hotmail and Silverlight, and the one that Varun calls out in Comment 54. http://mac.oldapps.com/silverlight.php?old_silverlight=1202 is a link to the 4.0 version of Silverlight. I don't believe anyone on the QA side has been able to successfully reproduce the crash, so I am not sure we will be able to verify the new version of Silverlight eliminates the hotmail/outlook crash.
Marcia, I agree, there are two crashes here. The largest and most prevalent is the hotmail one, and the smaller one is the Comment 54 Crash. I've got many users who've confirmed that the latest version of silverlight fixes the first issue.
Regarding my steps in Comment 41, if I have a new version of Silverlight installed (Version: 5.1.10411.0), I do not see the Restart in 32 bit mode info bar. As Tyler points out in Comment 58, updating to the latest version seems to fix the crash issue for those individuals. I assume that we have a SUMO article we can point users to that are having this particular issue? Varun's crash with lifehacker/gawker/jezebel is still one I have been unable to reproduce on my various Macs using trackpad and various different mice. I also sent out an email yesterday to the QA team asking them to try scrolling on those sites to see if they could generate a crash, but I haven't got any responses back as yet.
(In reply to Marcia Knous [:marcia] from comment #60) > I assume that we have a SUMO article we can point users to that are having > this particular issue? As users don't know that this issue is caused by Silverlight, the article is https://support.mozilla.org/kb/firefox-crashes-troubleshoot-prevent-and-get-help For contributors to the support forum, I renamed the bug summary.
Summary: crash in nsGfxScrollFrameInner::ScrollToImpl → crash in nsGfxScrollFrameInner::ScrollToImpl mainly with Silverlight 4
nsGfxScrollFrameInner::ScrollToImpl shows 1646 crashes in the last week across all versions. As noted in Comment 60, I don't believe any of us in QA have been able to reproduce the crash with Gawker/Jezebel/Lifehacker. So I don't know what else we can do to try to move forward on those crashes. Firefox users who are hitting the "Restart in 32 bit mode" issue with Silverlight/Hotmail/Outlook should be directed to update their Silverlight version if they come to SUMO.
At this point, I propose that we mark wontfix for Firefox 15, track for Firefox 16, possibly stage a Silverlight 4 block before Firefox 15's release, and do our due diligence to communicate via SUMO and RelNote.
Working on a blocklist here in bug 782672
Depends on: 782672
Bug 782672 has now landed, and we'll watch to make sure this crash falls off before marking as fixed.
In 14.0.1, it accounts for 3.4% of all Mac crashes over the last week, but only 1.8% over the last 3 days and 1% over the last day, so the blocklist seems to do the job.
Great, no need to track in that case.
tracking-firefox16: + → -
Mac crashes are still happening on Beta, Aurora and Trunk and I just added [@ nsGfxScrollFrameInner::AsyncScrollCallback] which is another manifestation of the signature.
Crash Signature: [@ nsGfxScrollFrameInner::ScrollToImpl ] [@ @0x0 | nsGfxScrollFrameInner::ScrollToImpl ] → [@ nsGfxScrollFrameInner::ScrollToImpl ] [@ @0x0 | nsGfxScrollFrameInner::ScrollToImpl ] [@ nsGfxScrollFrameInner::AsyncScrollCallback]
I forgot to add in Comment 68 that the these crashes are probably the other manifestation of the crash (Comment 51), but the URLs in the most recent crash reports do not reflect those sites (gawker, jezebel, etc). Will do some more digging, but one person was mentioning crashing on the huffingtonpost.com.
New crash on Fx16b1: http://crash-stats.mozilla.com/report/index/bp-43496fd6-d45f-4309-8e41-0969d2120903 on lifehacker.com. Sorry to say, moz-regression didn't reveal a glitch ... not sure why. Maybe an interaction between a plugin and Fx?
Is there a full debug build available, or a way to increase the logging so we can see just exactly what is happening in the last few milliseconds before the crash? I'd build it myself, but I just don't have Xcode installed and it is not available any longer from Apple for 10.6.8. Plus, guarantee I'll botch the compilation somehow.
Depends on: 788436
I've tried to reproduce the crash on a Mac OSX 10.7.5 machine, running Firefox 14.0.1, but without luck. For this, I opened the links suggested in comment 28, the link at the end of comment 21: http://lifehacker.com/5921048/how-can-i-sleep-through-the-night, and the following add-ons installed: Adblock Edge 2.0.2, Adblock Lite 1.4.3, Adblock Plus 2.2.1, and Adblock Plus Pop-up Addon 0.5
Bug 598397 landed for 19, and I think that should fix these crashes. Indeed I don't see any crashes on 19 or newer, only 18 or older. I don't know if there is much we can do for 18 now that it is released, so in that case I think we should just wait for 19 to fix this.
And this doesn't appear to be in the top 300 crashers in any current version.
(In reply to Timothy Nikkel (:tn) from comment #75) > And this doesn't appear to be in the top 300 crashers in any current version. That's because Windows crashes overshadow Linux and Mac due to how our users are spread over OSes. It's #12 on https://crash-stats.mozilla.com/topcrasher/byos/Firefox/18.0/Mac%20OS%20X/7/browser but based on the criteria at https://wiki.mozilla.org/CrashKill/Topcrash I think we're safe to remove the topcrash keyword. Actually, do we want to mark it fixed by bug 598397 in some way? dupe?
Keywords: topcrash
Depends on: 598397
Keywords: regressionwindow-wanted
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:25.0) Gecko/20130731 Firefox/25.0 I couldn't reproduce the crash on the latest Nightly (I followed all the instructions available in Comments 21,36,37,41 and 51). Also, I checked the Socorro reports and I couldn't find any recent crashes on the latest Firefox versions (Firefox 22, 23, 24 or 25 - the newest crashes were correlated with Firefox 18). Considering all this, I'm removing the qawanted keyword. Please re-add it if you have more details about how the issue can be reproduced.
Keywords: qawanted
There have been no crashes for the last four weeks after 18.0.1.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.