Closed Bug 1207993 Opened 10 years ago Closed 5 years ago

crash in igd10umd32.dll coming from mozilla::layers::DataTextureSourceD3D11::Update, at playing video on YouTube

Categories

(Core :: Graphics, defect, P3)

Product:
Core
Component:
Graphics
Version:
41 Branch
Platform:
x86
Windows 7
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
platform-rel --- -
firefox41 - wontfix
firefox42 + wontfix
firefox43 + wontfix
firefox44 + wontfix
firefox45 --- wontfix
firefox46 --- wontfix
firefox47 --- affected
firefox48 --- affected
firefox49 --- affected
firefox-esr45 --- affected
firefox50 --- affected

People

(Reporter: masayuki, Assigned: mattwoodrow, NeedInfo)

References

(Depends on 1 open bug)

Details

(Keywords: crash, regression, Whiteboard: [gfx-noted] [platform-rel-Youtube])

Crash Data

This bug was filed from the Socorro interface and is report bp-7343227b-f49a-49b9-80f0-c760a2150923. ============================================================= > Ø 0 igd10umd32.dll igd10umd32.dll@0x18f35 > Ø 1 igd10umd32.dll igd10umd32.dll@0x7a07 > Ø 2 igd10umd32.dll igd10umd32.dll@0x7024 > Ø 3 igd10umd32.dll igd10umd32.dll@0x335f > 4 xul.dll mozilla::layers::DataTextureSourceD3D11::Update(mozilla::gfx::DataSourceSurface*, nsIntRegion*, mozilla::gfx::IntPointTyped<mozilla::gfx::UnknownUnits>*) > 5 xul.dll mozilla::layers::DIBTextureHost::UpdatedInternal(nsIntRegion const*) > 6 xul.dll mozilla::layers::TextureHost::Updated(nsIntRegion const*) > 7 xul.dll mozilla::layers::ContentHostSingleBuffered::UpdateThebes(mozilla::layers::ThebesBufferData const&, nsIntRegion const&, nsIntRegion const&, nsIntRegion*) > 8 xul.dll mozilla::layers::CompositableParentManager::ReceiveCompositableUpdate(mozilla::layers::CompositableOperation const&, std::vector<mozilla::layers::EditReply, std::allocator<mozilla::layers::EditReply> >&) > 9 xul.dll mozilla::layers::LayerTransactionParent::RecvUpdate(nsTArray<mozilla::layers::Edit>&&, unsigned __int64 const&, mozilla::layers::TargetConfig const&, nsTArray<mozilla::layers::PluginWindowData>&&, bool const&, bool const&, unsigned int const&, bool const&, mozilla::TimeStamp const&, nsTArray<mozilla::layers::EditReply>*) This is really similar to bug 1202700, but bug 1202700 was marked as unaffected 41.
It was marked unaffected for 41 and 42 due to backout of bug 1193547, the actual patch is only in 43.
Summary: crash in igd10umd32.dll@0x18f35 at playing video on YouTube → crash in igd10umd32.dll@0x18f35 coming from mozilla::layers::DataTextureSourceD3D11::Update, at playing video on YouTube
Do we need additional blacklisting?
Flags: needinfo?(matt.woodrow)
Whiteboard: [gfx-noted]
[Tracking Requested - why for this release]: The signature igd10umd32.dll@0x18f35 itself is a topcrash right now. #5 in Firefox 41 with 1.40% of the volume. #18 in Firefox 42 with 0.62% of the volume. Firefox 43 has zero reports with this signature. Firefox 44 has zero reports with this signature. I'm not sure what percentage of these are in mozilla::layers::DataTextureSourceD3D11::Update though.
status-firefox41: --- → affected
status-firefox42: --- → affected
status-firefox43: --- → unaffected
status-firefox44: --- → unaffected
tracking-firefox41: --- → ?
tracking-firefox42: --- → ?
Keywords: topcrash-win
Do we have any idea what changed to make this drop off? We could try blacklisting for beta, but it looks like it's already down considerably there.
Flags: needinfo?(matt.woodrow)
Tracking as it is a top crash.
tracking-firefox42: ? → +
(In reply to Matt Woodrow (:mattwoodrow) from comment #4) > Do we have any idea what changed to make this drop off? I'm not so certain this "dropped off". I don't have data to say whether this has changed significantly in Firefox 41 and 42. As for the "zero reports" in Aurora and Nightly, that may just be a symptom of the users and hardware on those branches. We have no way of knowing for sure until Firefox 43/44 get into Beta/Release.
Even if 42 is still crash, it seems unlikely that it is going to be fixed in 42. Updating the flags accordingly.
status-firefox41: affected → wontfix
status-firefox42: affected → wontfix
tracking-firefox41: ? → -
anthony can you run a driver version correlation? I wonder if this is a 'sister' bug to bug 1221348. I can't find how to run them myself. Is there information on this?
Flags: needinfo?(anthony.s.hughes)
Driver Correlations: ==================== 1 8.15.10.1892 2891 39.32 % 2 8.15.10.1883 1592 21.65 % 3 8.15.10.1855 1246 16.95 % 4 8.15.10.1872 749 10.19 % 5 8.15.10.1851 440 5.98 % 6 8.15.10.1994 428 5.82 % 7 8.15.10.2020 4 0.05 % 8 8.640.4.1000 1 0.01 % 9 8.652.1.0 1 0.01 %
Flags: needinfo?(anthony.s.hughes)
This correlated with the same driver range as bug 1221348.
Some URLs from the comments: https://www.youtube.com/watch?v=yBJEP4lsRFY https://www.youtube.com/watch?v=qKoLcyDGalw A lot of users also report crashes while viewing Facebook clips. A lot of comments mention that the crash happens halfway through a video.
I haven't been able to reproduce this crash.
I see a few on 45 (e.g., https://crash-stats.mozilla.com/report/index/a34e0fff-e22c-44d1-930e-be6a82151125). I'm not sure the numbers are lower because things are better, they may very well be because of the distribution of graphics cards.
[Tracking Requested - why for this release]: So this is 1.3% of all 43.0 crashes, a lot of comments are really angry, URLs are mostly Facebook and YouTube, which are our most-heavy MSE video users. This is the worst gfx issue we have on release right now.
status-firefox43: unaffected → affected
status-firefox44: unaffected → affected
tracking-firefox43: --- → ?
tracking-firefox44: --- → ?
Milan, is there something we can do somewhat easily like some blocklisting? In any case, can we have someone to find out how we can mitigate this?
Flags: needinfo?(milan)
Matt, can you tell from the crash report or the stack (e.g., https://crash-stats.mozilla.com/report/index/92909008-8951-4503-8546-1df9e2151216) when the video is DXVA or not?
Flags: needinfo?(milan) → needinfo?(matt.woodrow)
Tracking for 43. We are planning to go to build for 43.0.2 on MOnday. I hope we can use the blocklist here though.
tracking-firefox43: ? → +
Was bug 1193547 the cause of this regression?
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #21) > Was bug 1193547 the cause of this regression? I have to admit, it is a bit confusing. Bug 1193547 landed on 43, got uplifted to 41 and 42, then got backed out of 41 and 42. Did we keep getting the crashes in 41 and 42 after the backout? If not, that but could be the cause. Also if we're already blocking these from DXVA, blocklisting won't help. There are at least some that are suggesting we're attempting to block (https://crash-stats.mozilla.com/report/index/6e950b4e-9707-4311-bcd8-2fc4e2151216) because of crashes during the sanity start up test), but I'm not sure if all of them are in the software fallback mode - and bug 1193547 is about that. So, I do want to understand if we can tell if we're accelerating or not based on the crash reports. Time zones may help us here - Matt will be at work around Sunday noon PST time.
Matt may be on PTO Monday. Hold on.
Assignee: nobody → matt.woodrow
Flags: needinfo?(milan)
A quick sanity test - is it OK that we have D3D9 DXVA manager, but are otherwise using D3D11?
(In reply to Milan Sreckovic [:milan] from comment #24) > A quick sanity test - is it OK that we have D3D9 DXVA manager, but are > otherwise using D3D11? Never mind, looks like we do want to do this by default.
Chris and Jean-Yves reviewed bug 1193547, maybe one of them is not on PTO.
Flags: needinfo?(jyavenard)
Flags: needinfo?(cpearce)
Bas, you're also in earlier on Monday than the NA folks - can you look at this, video or not...
Flags: needinfo?(bas)
(In reply to Milan Sreckovic [:milan] from comment #27) > Bas, you're also in earlier on Monday than the NA folks - can you look at > this, video or not... 'Cause, partial surface upload and all. Maybe bad parameters. Jeff, you can I can check on Monday, using the actual crash dump? Sorry for all the NI's on this bug, but we need to get to the bottom of this - see comment 15 and comment 20.
Flags: needinfo?(jmuizelaar)
From a media standpoint, all bug 1193547 was doing was detect if using the hardware decoder failed, and if so fall back to the software decoder. So in the case of hardware decoding, the picture frame returned would be GPU backed. Now that may expose a bug in the compositor. You can see from the backtrace that nowhere is the media stack involved. So really that is unrelated to the media stack and the fix would be beyond my area of expertise so I'm not sure I may be able to help. You may want to revert that patch, but if so it will introduce other regressions. But seeing it wasn't in 42 either it probably doesn't matter that much. Reverting bug 1193547 wouldn't fix the problem, it just work around calling a buggy code path. But if the fix is urgent, there may not be any other way.
Flags: needinfo?(jyavenard)
(In reply to Jean-Yves Avenard [:jya] from comment #29) > From a media standpoint, all bug 1193547 was doing was detect if using the > hardware decoder failed, and if so fall back to the software decoder. > So in the case of hardware decoding, the picture frame returned would be GPU > backed. > > Now that may expose a bug in the compositor. You can see from the backtrace > that nowhere is the media stack involved. So really that is unrelated to the > media stack and the fix would be beyond my area of expertise so I'm not sure > I may be able to help. > > You may want to revert that patch, but if so it will introduce other > regressions. But seeing it wasn't in 42 either it probably doesn't matter > that much. > > Reverting bug 1193547 wouldn't fix the problem, it just work around calling > a buggy code path. But if the fix is urgent, there may not be any other way. The crash itself happens pretty deep inside the intel drivers, it could be media is at least somehow involved. We need to get a minidump for one of these and check if I may be wrong and we're passing a null ptr to UpdateSubresource somehow. That in itself would most certainly explain the crash without the drivers being at fault.
Flags: needinfo?(bas)
I've examined the minidump for this crash and concluded all the parameters we're passing to UpdateSubResource are valid. mTexture could not be verified as it doesn't live on the stack and therefor isn't in the minidump, however the context in this function guarantees mTexture cannot be null. So this crash is basically guaranteed to be an actual bug in the intel drivers. It could be related to something media is doing, but it's impossible to say that for sure without having an environment where we can reproduce this.
We're going to try and reproduce in Toronto, we do have a 0x2a42 device. At least some of the crashes are on the systems where hardware video decoding should be disabled. It is also quite possible that the spike is because Facebook bumped up the use of HTML5 videos.
Flags: needinfo?(milan)
I'll produce a downloadable blocklist entry for the majority of these devices; we haven't been able to reproduce this yet, so I don't see us being able to produce the "in code" fix soon enough for 42.0.*
This blocklist entry should disable all acceleration features on Windows 7, Intel device 0x2a42 (most common in these crashes) devices for all drivers between 8.15.10.1800 and 8.15.10.1999 (inclusive.) That's a big hammer we're using, but it isn't clear where the issue lies, so we may not want to discover new code paths by only disabling some of the functionality. If we do find a workaround, we can modify this blocklist entry to only apply to versions of Firefox without that workaround. If we do not, we can disable all of these devices and drivers - for right now, some of the incoming reports may help us figure out what's going on. I'll get this reviewed before requesting update to the downloadable blocklist. <gfxBlacklistEntry> <os>WINNT 6.1</os> <vendor>0x8086</vendor> <devices> <device>0x2a42</device> </devices> <featureStatus>BLOCKED_DRIVER_VERSION</featureStatus> <driverVersion>8.15.10.1800</driverVersion> <driverVersionMax>8.15.10.1999</driverVersionMax> <driverVersionComparator>BETWEEN_INCLUSIVE</driverVersionComparator> </gfxBlacklistEntry>
This is another option - all features, all OS versions on these offending devices. <gfxBlacklistEntry> <vendor>0x8086</vendor> <devices> <device>0x2a42</device> <device>0x2e22</device> <device>0x2e12</device> <device>0x2e32</device> </devices> <featureStatus>BLOCKED_DRIVER_VERSION</featureStatus> <driverVersion>8.15.10.1800</driverVersion> <driverVersionMax>8.15.10.1999</driverVersionMax> <driverVersionComparator>BETWEEN_INCLUSIVE</driverVersionComparator> </gfxBlacklistEntry>
(In reply to Jean-Yves Avenard [:jya] from comment #29) > From a media standpoint, all bug 1193547 was doing was detect if using the > hardware decoder failed, and if so fall back to the software decoder. > ... Right; it caused bug 1202700 which had the same signature, which is why it got flagged. But, yes, it's likely just exposing a bug elsewhere or in the driver.
Somewhat randomly, 0x60 appears to be the config location for the Intel PCI config. This is likely completely coincidental, but it does feature prominently in the code for the Linux drivers (e.g., intel_i915_setup_chipset_flush()), so I thought I'd mention it.
The function that's crashing is doing a bunch of floating point arithmetic which seems a bit unusual.
Flags: needinfo?(jmuizelaar)
We also don't seem to hit that particular instruction when playing youtube
We had a decoding failure with ffmpeg with a format I had never heard of before, bug 1233340. Very long shot, but could it be 12bpp YUV420 causing the problem?
<gfxBlacklistEntry> <vendor>0x8086</vendor> <devices> <device>0x2a42</device> <device>0x2e22</device> <device>0x2e12</device> <device>0x2e32</device> <device>0x0046</device> </devices> <featureStatus>BLOCKED_DRIVER_VERSION</featureStatus> <driverVersion>8.15.10.1800</driverVersion> <driverVersionMax>8.15.10.1999</driverVersionMax> <driverVersionComparator>BETWEEN_INCLUSIVE</driverVersionComparator> </gfxBlacklistEntry>
The crash seems to happen when a driver call in the igd10umd32.dll@0x7800 function to d3d11!NDXGI::DeviceLockCB fails.
If we could know why this function was failing in these crashes that would help a lot in figuring out the problem.
(In reply to Milan Sreckovic [:milan] from comment #41) > <gfxBlacklistEntry> > <vendor>0x8086</vendor> > <devices> > <device>0x2a42</device> > <device>0x2e22</device> > <device>0x2e12</device> > <device>0x2e32</device> > <device>0x0046</device> > </devices> > <featureStatus>BLOCKED_DRIVER_VERSION</featureStatus> > <driverVersion>8.15.10.1800</driverVersion> > <driverVersionMax>8.15.10.1999</driverVersionMax> > <driverVersionComparator>BETWEEN_INCLUSIVE</driverVersionComparator> > </gfxBlacklistEntry> This seems sane. Let's stop the bleeding for now and continue to try figure out what's going on.
Jorge, can you add the item from comment 41 to the downloadable blocklist?
Flags: needinfo?(jorge)
Depends on: 1234354
Going to try and find out if we have any of these matching crashes during the startup sanity test once bug 1234362 enables us to search for those.
See Also: → 1234362
Some of the crashes have "Too many dropped/corrupted frames, disabling DXVA"
Looks like driverVersionMax is new and isn't supported on the blocklisting forms on AMO. I filed an issue for this (https://github.com/mozilla/olympia/issues/1123), but I don't know how long it will take to be fixed.
Flags: needinfo?(jorge)
Ouch - thanks for filing that bug. In the meantime, we'll go with the explicit versions that were showing up the most: <gfxBlacklistEntry> <vendor>0x8086</vendor> <devices> <device>0x2a42</device> <device>0x2e22</device> <device>0x2e12</device> <device>0x2e32</device> <device>0x0046</device> </devices> <featureStatus>BLOCKED_DRIVER_VERSION</featureStatus> <driverVersion>8.15.10.1851</driverVersion> <driverVersionComparator>EQUAL</driverVersionComparator> </gfxBlacklistEntry> <gfxBlacklistEntry> <vendor>0x8086</vendor> <devices> <device>0x2a42</device> <device>0x2e22</device> <device>0x2e12</device> <device>0x2e32</device> <device>0x0046</device> </devices> <featureStatus>BLOCKED_DRIVER_VERSION</featureStatus> <driverVersion>8.15.10.1855</driverVersion> <driverVersionComparator>EQUAL</driverVersionComparator> </gfxBlacklistEntry> <gfxBlacklistEntry> <vendor>0x8086</vendor> <devices> <device>0x2a42</device> <device>0x2e22</device> <device>0x2e12</device> <device>0x2e32</device> <device>0x0046</device> </devices> <featureStatus>BLOCKED_DRIVER_VERSION</featureStatus> <driverVersion>8.15.10.1872</driverVersion> <driverVersionComparator>EQUAL</driverVersionComparator> </gfxBlacklistEntry> <gfxBlacklistEntry> <vendor>0x8086</vendor> <devices> <device>0x2a42</device> <device>0x2e22</device> <device>0x2e12</device> <device>0x2e32</device> <device>0x0046</device> </devices> <featureStatus>BLOCKED_DRIVER_VERSION</featureStatus> <driverVersion>8.15.10.1883</driverVersion> <driverVersionComparator>EQUAL</driverVersionComparator> </gfxBlacklistEntry> <gfxBlacklistEntry> <vendor>0x8086</vendor> <devices> <device>0x2a42</device> <device>0x2e22</device> <device>0x2e12</device> <device>0x2e32</device> <device>0x0046</device> </devices> <featureStatus>BLOCKED_DRIVER_VERSION</featureStatus> <driverVersion>8.15.10.1892</driverVersion> <driverVersionComparator>EQUAL</driverVersionComparator> </gfxBlacklistEntry> <gfxBlacklistEntry> <vendor>0x8086</vendor> <devices> <device>0x2a42</device> <device>0x2e22</device> <device>0x2e12</device> <device>0x2e32</device> <device>0x0046</device> </devices> <featureStatus>BLOCKED_DRIVER_VERSION</featureStatus> <driverVersion>8.15.10.1994</driverVersion> <driverVersionComparator>EQUAL</driverVersionComparator> </gfxBlacklistEntry>
Flags: needinfo?(jorge)
(In reply to Jorge Villalobos [:jorgev] from comment #49) > Looks like driverVersionMax is new and isn't supported on the blocklisting > forms on AMO. I filed an issue for this > (https://github.com/mozilla/olympia/issues/1123), but I don't know how long > it will take to be fixed. And I just realized that driverVersionMax field isn't supported in the code either. So, I'd appreciate it if we can fix this issue in "olympia", but the urgency is not as critical, given that we need to also add this support into the code. I'll open a separate bug for that. In the meantime, comment 50 is the way to go.
Okay, it's done.
Flags: needinfo?(jorge)
(In reply to Jeff Muizelaar [:jrmuizel] from comment #44) > If we could know why this function was failing in these crashes that would > help a lot in figuring out the problem. From reading the code it looks like it's not WASSTILLDRAWING or DEVICEREMOVED
(In reply to Jeff Muizelaar [:jrmuizel] from comment #53) > (In reply to Jeff Muizelaar [:jrmuizel] from comment #44) > > If we could know why this function was failing in these crashes that would > > help a lot in figuring out the problem. > > From reading the code it looks like it's not WASSTILLDRAWING or DEVICEREMOVED Simulating the function returning E_OUTOFMEMORY is not sufficient to reproduce the crash.
(In reply to Jeff Muizelaar [:jrmuizel] from comment #54) > (In reply to Jeff Muizelaar [:jrmuizel] from comment #53) > > (In reply to Jeff Muizelaar [:jrmuizel] from comment #44) > > > If we could know why this function was failing in these crashes that would > > > help a lot in figuring out the problem. > > > > From reading the code it looks like it's not WASSTILLDRAWING or DEVICEREMOVED > > Simulating the function returning E_OUTOFMEMORY is not sufficient to > reproduce the crash. We end up calling the crashing function but it looks like something else needs to go wrong for us to actually crash.
Still looking like a topcrash on 43 though.
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #57) > Still looking like a topcrash on 43 though. Hopefully this slows down as the blocklist gets updated for these users.
Should we be locking (keyed mutex) mTexture before calling UpdateSubresource? Would that help, hurt, do nothing?
Flags: needinfo?(jmuizelaar)
Flags: needinfo?(bas)
It appears the blocklist is holding these crashes back.
(In reply to Milan Sreckovic [:milan] from comment #60) > Should we be locking (keyed mutex) mTexture before calling > UpdateSubresource? Would that help, hurt, do nothing? If we were using them we should, but that's not the case in this stack.
Flags: needinfo?(bas)
I'm not sure how much I can help here... One idea; the DXVA documentation mentions locking the D3D devices: https://msdn.microsoft.com/en-us/library/windows/desktop/ms697056%28v=vs.85%29.aspx We seem to be not doing that. I tried that when I did the initial DXVA support, but it made playback performance slow to a crawl on my machine. So maybe I wasn't doing it right. It's a bit hard to know for sure whether enabling that again would help without a repro.
Flags: needinfo?(cpearce)
I'm not sure this is DXVA related as we currently hit it on devices that have DXVA disabled.
I don't think this blocking is working.
Flags: needinfo?(milan)
For example: https://crash-stats.mozilla.com/report/index/91d5502c-6240-4271-8cb6-5a8dc2160129, despite: <gfxBlacklistEntry> <vendor>0x8086</vendor> <devices> <device>0x2a42</device> <device>0x2e22</device> <device>0x2e12</device> <device>0x2e32</device> <device>0x0046</device> </devices> <featureStatus>BLOCKED_DRIVER_VERSION</featureStatus> <driverVersion>8.15.10.1872</driverVersion> <driverVersionComparator>EQUAL</driverVersionComparator> </gfxBlacklistEntry>
Flags: needinfo?(milan)
It looks like if you don't have a suggested version for blocking driver versions we don't block: https://dxr.mozilla.org/mozilla-central/source/widget/GfxInfoBase.cpp#1020
Flags: needinfo?(jmuizelaar)
The situation is even worse. There does not appear to be a way to specify a suggested version. This implies that the only driver block list entries that work are those that use LESS_THAN which have an implicit suggested version.
Not quite that bad. This code https://dxr.mozilla.org/mozilla-central/source/widget/GfxInfoBase.cpp#1020 just means we don't save the blocking status in a pref, but we're still blocking. The actual problem here is that the specification from comment 50 does not have the <os></os> values set. While the absence of <feature> means "all features", the absence of <os> means "undefined OS". We need to add <os>All</os> to all the entries above. We'll test this on one of the affected systems first and confirm.
Flags: needinfo?(jmuizelaar)
I tried testing it and it didn't work. Then I realized I had typo'd All as ALL :( It worked when I fixed that. Jorge can you <os>All</os> to the entries above?
Flags: needinfo?(jmuizelaar) → needinfo?(jorge)
Done.
Flags: needinfo?(jorge)
Flags: needinfo?(matt.woodrow)
We had 34,655 crashes in the month before we pushed the block live on February 9th. Since then we've seen 5,173 crashes, mostly on older Firefox versions: > Firefox 46: 17 crashes since 2016-02-10 [ 0.32%] > Firefox 45: 272 crashes since 2016-02-10 [ 5.26%] > Firefox 43: 797 crashes since 2016-02-10 [15.40%] > Firefox 35: 2197 crashes since 2016-02-10 [42.47%] In the last week we've seen 213 crashes, again mostly on older Firefox versions: > Firefox 46: 8 crashes since 2016-04-30 [ 3.76%] > Firefox 45: 24 crashes since 2016-04-30 [11.27%] > Firefox 43: 12 crashes since 2016-04-30 [ 5.63%] > Firefox 35: 114 crashes since 2016-04-30 [53.52%] The blocked driver version has declined to 4th overall: > 8.15.10.1892: 42 crashes since 2016-04-30 [54.55%] > 8.15.10.1855: 9 crashes since 2016-04-30 [11.69%] > 8.15.10.1883: 9 crashes since 2016-04-30 [11.69%] > 8.15.10.1872: 5 crashes since 2016-04-30 [ 6.49%] > 8.15.10.1994: 4 crashes since 2016-04-30 [ 5.19%] Based on this information I would say the block is not 100% effective although it has improved the situation. It doesn't even break in to the top-300 crashes for Firefox 46.0.1.
status-firefox45: ? → wontfix
status-firefox46: ? → wontfix
status-firefox47: --- → ?
status-firefox48: --- → ?
status-firefox49: --- → ?
Keywords: topcrash-win
platform-rel: --- → ?
Whiteboard: [gfx-noted] → [gfx-noted] [platform-rel-Youtube]
platform-rel: ? → +
Crash volume for signature 'igd10umd32.dll@0x18f35': - nightly (version 50): 0 crashes from 2016-06-06. - aurora (version 49): 0 crashes from 2016-06-07. - beta (version 48): 2 crashes from 2016-06-06. - release (version 47): 31 crashes from 2016-05-31. - esr (version 45): 48 crashes from 2016-04-07. Crash volume on the last weeks: W. N-1 W. N-2 W. N-3 W. N-4 W. N-5 W. N-6 W. N-7 - nightly 0 0 0 0 0 0 0 - aurora 0 0 0 0 0 0 0 - beta 0 0 0 0 0 0 1 - release 0 0 0 0 0 10 16 - esr 0 0 0 0 0 2 13 Affected platform: Windows
status-firefox-esr45: --- → affected
Rank: 7
Crash Signature: [@ igd10umd32.dll@0x18f35] → [@ igd10umd32.dll@0x18f35] [@ igd10umd32.dll | mozilla::layers::DataTextureSourceD3D11::Update]
Note that this doesn't appear to be vendor specific, and while this bug is tracking it for Intel devices, there are equivalent crashes on other vendors (e.g., https://crash-stats.mozilla.com/report/index/87236fa8-a3ab-4edc-a4d6-5cf842161026)
Summary: crash in igd10umd32.dll@0x18f35 coming from mozilla::layers::DataTextureSourceD3D11::Update, at playing video on YouTube → crash in igd10umd32.dll coming from mozilla::layers::DataTextureSourceD3D11::Update, at playing video on YouTube
No new crashes in 51 and 52, could be fixed by the recent video changes we made. These seem to be driver reset related, quite likely from OOM like situation.
(In reply to Milan Sreckovic [:milan] from comment #76) > No new crashes in 51 and 52, could be fixed by the recent video changes we > made. These seem to be driver reset related, quite likely from OOM like > situation. With no new crashes in 51 + 52, should this be closed :milan?
Flags: needinfo?(milan)
(In reply to Desigan Chinniah [:cyberdees] [:dees] [London - GMT] from comment #77) > (In reply to Milan Sreckovic [:milan] from comment #76) > > No new crashes in 51 and 52, could be fixed by the recent video changes we > > made. These seem to be driver reset related, quite likely from OOM like > > situation. > > With no new crashes in 51 + 52, should this be closed :milan? Sounds about right. Anthony, I'll let you double check my queries and close it if appropriate.
Flags: needinfo?(milan) → needinfo?(anthony.s.hughes)
We've had very few crashes with 51 beta so far, but let's wait next week (when we release 51 to the release channel) before calling it fixed (the crash volume on the beta channel has always been small).
status-firefox47: ? → affected
status-firefox48: ? → affected
status-firefox49: ? → affected
status-firefox50: --- → affected
There are still crashes in 51, but with a very small volume (20 crashes over the past week).
I don't think this is vendor specific bug - see bug 1310600 for Nvidia, for example. There are a few variations, but all in the partial upload. ~60% in bad WRITE, the rest in bad READ.
Flags: needinfo?(milan)
See Also: → 1310600
It's also probably not partial update related - here's one example of the full update: https://crash-stats.mozilla.com/report/index/c84ca10c-5ce9-46fc-8948-ce64b2170301 (read failure)
See Also: → 1405110

In the last three months there are almost no crashes newer than version 52.
beyond a few of version 60.x, there is only one version 72 bp-fb8d2159-283a-4c8c-a847-d9b770191209

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Keywords: regression

Closing because no crashes reported for 12 weeks.

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