Closed Bug 1054954 Opened 10 years ago Closed 3 years ago

Firefox crashes way too frequently (recent issue) - Possibly related to the display driver (Intel HD Graphics 3000)

Categories

(Core :: Graphics: Layers, defect)

31 Branch
x86
Windows 7
defect
Not set
major

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: galar71, Unassigned)

Details

(Keywords: crash, Whiteboard: [platform-rel-Intel])

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release)
Build ID: 20140716183446

Steps to reproduce:

I can't really reproduce the bug. It frequently happens when I browse pictures though, such as when browsing a large album on Facebook, or when I browse pictures after a Yahoo search.

This is a Lenovo T420 with an Intel Core i5-2540 CPU @ 2.60 GHz, with a built-in Intel HD Graphics 3000 Gpu.


Actual results:

Crash. Sometimes when browsing pictures, other times when Firefox is seemingly idle.

The common denominator is that the crash reports contain the following in "App Notes":
"Cisco VPN
AdapterVendorID: 0x8086, AdapterDeviceID: 0x0126, AdapterSubsysID: 21ce17aa, AdapterDriverVersion: 9.17.10.2843
D2D? D2D+ DWrite? DWrite+ D3D10 Layers? D3D10 Layers+ WebGL? EGL? EGL+ GL Context? GL Context+ WebGL+ "

It reports Cisco VPN here, but this is actually the graphics driver for the Intel HD Graphics 3000 built-in Graphics device. It has happened on a couple of version of this driver, and it primarily surfaced a couple of weeks ago (Firefox 30 or 31).

Here are a few of the crash reports:
https://crash-stats.mozilla.com/report/index/bp-13dcae91-8ced-4c70-8991-b25f52140818
https://crash-stats.mozilla.com/report/index/bp-448c3807-40b1-4fb0-b9ac-4e1602140815
https://crash-stats.mozilla.com/report/index/1344ff9b-78ca-4b5c-98e9-36cde2140814
https://crash-stats.mozilla.com/report/index/0c8d1a97-27b0-4689-a75a-9ef9c2140814

I can provide many more of the crash reports if necessary.


Expected results:

Normal behavior - not crash.
Severity: normal → major
Component: Untriaged → Graphics: Layers
Product: Firefox → Core
https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=23764 64bit
https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=23763 32bit

Your graphics driver is very old, try updating to the latest Intel 9.17.10.3517 driver for Sandy Bridge.
Hi...

I have installed the drivers you recommended... I'll keep you posted as to how it goes...

Best Regards,
$Øyvind
Hi...

Ok... I browsed pictures on Instagram in order to try to reproduce the error condition. Unfortunately the new driver does not seem to make any difference - it crashed again (as normal).

Here's the Crash Report:
https://crash-stats.mozilla.com/report/index/41e28b70-6520-4215-889d-4d6b82140820

$Øyvind
(In reply to Øyvind from comment #3)
> Hi...
> 
> Ok... I browsed pictures on Instagram in order to try to reproduce the error
> condition. Unfortunately the new driver does not seem to make any difference
> - it crashed again (as normal).
> 
> Here's the Crash Report:
> https://crash-stats.mozilla.com/report/index/41e28b70-6520-4215-889d-
> 4d6b82140820
> 
> $Øyvind

This looks like bug 986502...

It's kind of odd that there seems to be comparatively little in common between:

https://crash-stats.mozilla.com/report/index/13dcae91-8ced-4c70-8991-b25f52140818
https://crash-stats.mozilla.com/report/index/0c8d1a97-27b0-4689-a75a-9ef9c2140814
https://crash-stats.mozilla.com/report/index/41e28b70-6520-4215-889d-4d6b82140820

(which are the non-graphics-driver crashes)

What happens if you disable your add-ons and plugins? Safe mode ("restart with add-ons disabled") would disable hardware acceleration, so that's not really an option (ie you'd have to disable add-ons manually), but it would be useful if we could correlate this with one or more of your add-ons. Alternatively, you could try to use a clean profile for a while (you'd still have to disable Norton manually in such a new profile).
Keywords: crash
Hi, Gijs...

I'll try to disable all add-ons and plug-ins manually when I have some time, and then I'll try to recreate the issue with everything disabled... From what I understand, it would be a useless test to try to recreate this in Safe Mode, so I'll stay clear of that and rather do the manual disable like you're suggesting.'

$Øyvind
Hi again...

I did as you suggested... I disabled all plugins and all add-ons, even reverted back to Default theme.

I managed to reproduce the error, although I feel I had to browse more pictures now, so it didn't happens as easily...

Here's the crash report:
https://crash-stats.mozilla.com/report/index/f1f9e410-8835-41f3-b0ea-296f62140822

$Øyvind
That's another crash that matches bug 986502. They're "out of memory" crashes where Firefox requests an allocation of memory (in this case for graphics-related things) and it basically gets told "no". Indeed, the app section contains a bundle of error messages with an error code that matches NS_ERROR_OUT_OF_MEMORY.

It makes sense that it takes longer without the add-ons - there's probably (significantly) less memory being used (or potentially leaked...). 

Can you confirm that at that point, Firefox is consuming a lot of memory (think upwards of 2gb, probably more than 3) ?

I'm not really sure how to pursue this further... njn, can you help?
Flags: needinfo?(n.nethercote)
Flags: needinfo?(galar71)
Hi...

The memory issue has crossed my mind too - especially since it seemed to take longer with add-ons and plugins disabled...

Yes, Firefox is usually consuming a lot of memory.. I'm not entirely sure which parameter I should use to determine the exact usage though... If I look in Task Manager, which values are you looking for?  I usually view memory usage on the "Working Set (Memory)" and "Commit Size" and they can easily be 5-600MB / 1.4GB respectively..

Something that's worth keeping in mind though is that I never get any Out of Memory issues reported by Windows, nor do I have any similar issue with other Applications that I know of..

I usually run Firefox with somewhere in the range of 30-60 tabs open, of which about 20 are pinned. I checked the two beforementioned values after startup, and they are about 650MB each.
Flags: needinfo?(galar71)
about:memory dumps at a point shortly prior to crashing (if possible) would be very useful. Please visit "about:memory" and use the "Measure and save..." button, and then attach the resulting file to this bug.
Flags: needinfo?(n.nethercote)
This is a memory dump as requested. I managed to take the dump more or less immediately before the crash.

$Øyvind
Group: core-security
I checked the "Sensitive" flag and saved, btw... Primarily due to the possibility the memory dump contains personal information...

If you need to, to properly resolve the issue, please uncheck it.

$Øyvind
Hiding the attachment. If anyone needs to see it to work on this bug please contact the security team (mail or #security), but I suspect the qualified people already have the necessary access.
Group: core-security
Thanks for the memory reports, Øyvind. Here are some of the more important measurements:

> 743.73 MB (100.0%) -- explicit
> ...
> ├──230.31 MB (30.97%) -- images
>
>     0.00 MB ── gfx-d2d-surface-cache
>     4.00 MB ── gfx-d2d-surface-vram
>    24.31 MB ── gfx-d2d-vram-draw-target
>   127.85 MB ── gfx-d2d-vram-source-surface
>     0.02 MB ── gfx-surface-win32
>     0.00 MB ── gfx-textures
> ...
>   265.84 MB ── gpu-committed
>     0.00 MB ── gpu-dedicated
>   313.80 MB ── gpu-shared
> ...
> 1,257.46 MB ── private
> 1,290.70 MB ── resident
> 1,814.73 MB ── vsize
>     7.00 MB ── vsize-max-contiguous

The last two are the most notable -- they suggest that you are close to running out of virtual address space, which is 2 GiB for many Windows machines. In the short term, there's not a great deal you can do about that, unfortunately.

I've CC'd dmajor who knows more about these kinds of crashes, in case he has anything else to add.
1814 vsize to 743 explicit is a really high ratio! There's a ton of address space not accounted for. In one of the minidumps I see about 500MB of write-combine pages, most of it in 8MB chunks, which I assume is graphics memory. :tn, is that normal for an image-heavy browsing session?

Firefox will struggle when there are dozens of active tabs on a 32-bit OS, since we're limited to 2GB of allocations. As a stopgap you could try using the "3GB switch" but it has limitations: http://knowledge.autodesk.com/support/autocad/troubleshooting/caas/sfdcarticles/sfdcarticles/How-to-enable-a-3GB-switch-on-Windows-Vista-Windows-7-or-Windows-XP-s.html
Flags: needinfo?(tnikkel)
(In reply to David Major [:dmajor] from comment #14)
> 1814 vsize to 743 explicit is a really high ratio! There's a ton of address
> space not accounted for. In one of the minidumps I see about 500MB of
> write-combine pages, most of it in 8MB chunks, which I assume is graphics
> memory. :tn, is that normal for an image-heavy browsing session?

I don't think that's normal, but it reminds me very strongly of bug 985193, where I see (on mac) a large discrepancy between resident and explicit. I haven't had any cycles to look into it any further than my last comment in that bug. Summary: images get layerized and then we seem to be failing to properly manage them and we keep around way too many resources.
Flags: needinfo?(tnikkel)
Øyvind, have you experienced this crash recently?
Flags: needinfo?(galar71)
Hi...

Yes, I'm still experiencing this issue - on a regular basis...

I'm running a slightly resource constrained 32-bit Windows 7 Enterprise, with Firefox 41.0.1, and the hardware is still the same as mentioned in the initial report.

I can usually reproduce the issue by either browsing large albums on Facebook (scroll down until it crashes), similarly on Instagram, or if I do an image search on Yahoo and scroll down...

These similar scenarios will usually start "destabilizing" the browser first, where parts of the window will go dark, and it will eventually crash abruptly.

It seems to me that it keeps on allocating memory, but never really releases any...

I regularly restart the browser, especially after I've had it running for a while...

Best Regards,
$Øyvind
Flags: needinfo?(galar71)
(In reply to Øyvind from comment #17)
> Hi...
> 
> Yes, I'm still experiencing this issue - on a regular basis...
> 
> I'm running a slightly resource constrained 32-bit Windows 7 Enterprise,
> with Firefox 41.0.1, and the hardware is still the same as mentioned in the
> initial report.

Out of curiosity, how much memory does your system have?
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #18)
> (In reply to Øyvind from comment #17)
> > Hi...
> > 
> > Yes, I'm still experiencing this issue - on a regular basis...
> > 
> > I'm running a slightly resource constrained 32-bit Windows 7 Enterprise,
> > with Firefox 41.0.1, and the hardware is still the same as mentioned in the
> > initial report.
> 
> Out of curiosity, how much memory does your system have?

Hi, Anthony...

It does have the maximum for 32-bit - 4GB of RAM.

$Øyvind
Whiteboard: [platform-rel-Intel]
platform-rel: --- → ?
platform-rel: ? → ---

Hello,

Its been a long time since the last update on this issue, does it still happen on latest Firefox versions (assuming you still use the same machine)?
If so, please add the crash signature so we could follow-up on Socorro. If not, we will close this issue.

Thank you!

Flags: needinfo?(galar71)

Hi...

This is several computers ago, so don't worry about it... It's likely fixed... Please just close the issue. :)

Best Regards,
$Øyvind

Flags: needinfo?(galar71)

(In reply to Øyvind from comment #21)

This is several computers ago, so don't worry about it... It's likely fixed... Please just close the issue. :)

Thanks, I'll update the bug with that info.

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.