Closed Bug 1346765 Opened 8 years ago Closed 7 years ago

crash in tosqep.dll/tosqep64.dll (toshiba av library)

Categories

(Core :: Audio/Video: Playback, defect, P2)

Product:
Core
Component:
Audio/Video: Playback
Version:
51 Branch
Platform:
All
Windows 10
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox52 --- wontfix
firefox-esr52 --- wontfix
firefox53 --- wontfix
firefox54 + wontfix
firefox55 - wontfix
firefox56 --- wontfix
firefox57 --- fixed

People

(Reporter: philipp, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: crash, regression)

Crash Data

+++ This bug was initially created as a clone of Bug #1268905 +++ these crashes with the toshiba tosqep.dll/tosqep64.dll seem to be reappearing in bigger numbers again since 2017-03-09. i checked a couple of those reports and their module list still showed that the same .dll versions were present that we blocklisted with bug 1273691. nevertheless DXVA2D3D11 playback seemed to be turned on in these reports. https://crash-stats.mozilla.com/signature/?product=Firefox&signature=tosqep.dll%400x7189&date=%3E%3D2017-03-01T00%3A00%3A00.000Z#graphs
I've downloaded the minidump from one of those reports, the DLL is not in System32: c:\Program Files (x86)\Common files\Toshiba Shared\TosQEP.dll. This means initially with bug 1273691 we wouldn't have blocked DXVA. With bug 1313339, we should block it. I'm not sure why it's not blocked. Perhaps the DLL isn't loaded yet when we run the blocklisting code? Is it possible?
Flags: needinfo?(gsquelart)
Not sure what's happening either, sorry. The only thing I can think of is "GPU process", maybe somehow it changes how DLLs are loaded and checked? (But don't trust the gut feeling) Otherwise we could try and block igd10umd32.dll 9.17.10.4459?
Mass wontfix for bugs affecting firefox 52.
status-firefox52: affected → wontfix
Marco, can we go ahead and block idg10umd32.dll as suggested in comment 2?
Flags: needinfo?(mcastelluccio)
The only thing I'm afraid of is that this could block acceleration for people that are unaffected by the crash. Around 1,74% of Firefox release users have the 9.17.10.4459 Intel driver, I bet in comparison a tiny amount of people have the Toshiba AV library.
Flags: needinfo?(mcastelluccio)
Wontfix at this point for 53. Anthony, do you have an opinion here for the right thing to do for 54/55? Here's a search to see the top crash reports where the signature contains "tosqep", though I'm not sure they would all be from the same cause: https://crash-stats.mozilla.com/search/?signature=~tosqep&product=Firefox&date=%3E%3D2017-04-20T21%3A44%3A00.000Z&date=%3C2017-04-27T21%3A44%3A00.000Z&_sort=-date&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature
status-firefox53: affected → wontfix
tracking-firefox54: --- → +
Flags: needinfo?(ajones)
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #7) > > https://hg.mozilla.org/mozilla-central/ > pushloghtml?fromchange=7513b3f42058e9bcf9950d4acf4647d4ad2240f0&tochange=01d1 > dedf400d4be413b1a0d48090dca7acf29637 > > Nothing looks especially suspicious. Sotaro - is it possible that bug > 1349232 fixes this issue? It is a fix for webrender enabled. So I do not think bug 1349232 fix affect to this bug.
Flags: needinfo?(sotaro.ikeda.g)
It's possible this has never been a problem on Nightly but only starting from Beta, because of the differences in the populations (perhaps only a few Nightly users have this DLL). If you look at the past 6 months, there's been a really small number of crashes on 54.0a1.
Could we use part of the code from bug 1362212, which is going to load the DLLs needed to play media, to make sure that the DLLs are loaded when we make the blocklisting decision? Or are those functions themselves using the blocklist code?
Chris, how do you think about comment 10?
Flags: needinfo?(cpearce)
(In reply to Marco Castelluccio [:marco] from comment #10) > Could we use part of the code from bug 1362212, which is going to load the > DLLs needed to play media, to make sure that the DLLs are loaded when we > make the blocklisting decision? > Or are those functions themselves using the blocklist code? The functions that my patches in bug 1362212 call should themselves using the blocklist code. I don't understand how the DLL could be blocklisted bu not blocked.
Flags: needinfo?(cpearce)
(In reply to Chris Pearce (:cpearce) from comment #12) > (In reply to Marco Castelluccio [:marco] from comment #10) > > Could we use part of the code from bug 1362212, which is going to load the > > DLLs needed to play media, to make sure that the DLLs are loaded when we > > make the blocklisting decision? > > Or are those functions themselves using the blocklist code? > > The functions that my patches in bug 1362212 call should themselves using > the blocklist code. I don't understand how the DLL could be blocklisted bu > not blocked. Is it possible that the DLLs are loaded in the process -after- we execute the blocklist?
Only a very small number of crashes are happening on e10s builds. This means that the crash rate will inevitably go down as e10s ramps up.
Too late for 54 as we've built 54 RC. Mark 54 won't fix.
status-firefox54: affected → wontfix
tracking-firefox55: --- → ?
Clearing needinfo, since Gerald replied in comment 2.
Flags: needinfo?(gsquelart)
I don't think we need to track this if the crash rate is going down dramatically for users who have e10s enabled. And, there are only about 50 crashes per week on 54 release.
status-firefox56: --- → ?
tracking-firefox55: ? → -
This is a P1 bug without an assignee. P1 are bugs which are being worked on for the current release cycle/iteration/sprint. If the bug is not assigned by Monday, 28 August, the bug's priority will be reset to '--'.
Keywords: stale-bug
Mass change P1->P2 to align with new Mozilla triage process
Priority: P1 → P2
100% of these tosqep.dll and tosqep64.dll crashes are on Windows 10. Bug 1268905 disabled D3D11 when these DLLs are present to avoid some crashes, but comment 0 here says D3D11 is enabled in these crash reports.
Crash Signature: tosqep.dll@0x9bda] [@ tosqep64.dll@0x8eb4] → tosqep.dll@0x9bda] [@ tosqep64.dll@0x8eb4] [@ tosqep64.dll@0xa07d]
status-firefox55: ? → wontfix
status-firefox56: ? → affected
status-firefox57: --- → affected
status-firefox58: --- → ?
OS: Windows → Windows 10
(In reply to Chris Peterson [:cpeterson] from comment #21) > 100% of these tosqep.dll and tosqep64.dll crashes are on Windows 10. > > Bug 1268905 disabled D3D11 when these DLLs are present to avoid some > crashes, but comment 0 here says D3D11 is enabled in these crash reports. Two different D3D11. bug 1268905 disabled the D3D11 DXVA h264 decoder (so that it falls back to the D3D9 h264 decoder) D3D11 is what the compositor is using on Windows, and it's either that or basic compositor.
At least some of the reports have "DXVA2D3D11? DXVA2D3D11+" in the app notes.
(In reply to Marco Castelluccio [:marco] from comment #13) > (In reply to Chris Pearce (:cpearce) from comment #12) > > (In reply to Marco Castelluccio [:marco] from comment #10) > > > Could we use part of the code from bug 1362212, which is going to load the > > > DLLs needed to play media, to make sure that the DLLs are loaded when we > > > make the blocklisting decision? > > > Or are those functions themselves using the blocklist code? > > > > The functions that my patches in bug 1362212 call should themselves using > > the blocklist code. I don't understand how the DLL could be blocklisted bu > > not blocked. > > Is it possible that the DLLs are loaded in the process -after- we execute > the blocklist? Probably before, or our dll blocklist fails to init.
Blocks: injecteject
(In reply to Jim Mathies [:jimm] from comment #24) > (In reply to Marco Castelluccio [:marco] from comment #13) > > (In reply to Chris Pearce (:cpearce) from comment #12) > > > (In reply to Marco Castelluccio [:marco] from comment #10) > > > > Could we use part of the code from bug 1362212, which is going to load the > > > > DLLs needed to play media, to make sure that the DLLs are loaded when we > > > > make the blocklisting decision? > > > > Or are those functions themselves using the blocklist code? > > > > > > The functions that my patches in bug 1362212 call should themselves using > > > the blocklist code. I don't understand how the DLL could be blocklisted bu > > > not blocked. > > > > Is it possible that the DLLs are loaded in the process -after- we execute > > the blocklist? > > Probably before, or our dll blocklist fails to init. This is a different kind of blocklist. It's not the DLL blocklist, but the DXVA blocklist that checks for the presence of a given DLL in order to block DXVA.
Since crash volume has nearly gone away (except for 52esr, from what I can tell...), did we forget to blocklist this on ESR? Do we want to bother doing that?
Flags: needinfo?(ryanvm)
Flags: needinfo?(mcastelluccio)
I think it was somehow fixed in 57. If you look at the past month (https://crash-stats.mozilla.com/search/?signature=~tosqep&product=Firefox&date=%3E%3D2017-11-06T17%3A59%3A53.000Z&date=%3C2017-12-06T17%3A59%3A53.000Z&_sort=-date&_facets=signature&_facets=version&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-version), there are crashes on 56 too. I have no idea what fixed this in 57, the blocklist addition was done way earlier than that.
Flags: needinfo?(mcastelluccio)
I mean, we *could* do the blocklisting on ESR52 also, but the volume is so low that I'm not sure it's worth bothering.
Flags: needinfo?(ryanvm)
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox56: affected → wontfix
status-firefox57: affected → fixed
status-firefox58: ? → ---
status-firefox-esr52: affected → wontfix
Keywords: stale-bug
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.