Crash in CContext::ID3D11DeviceContext1_Map_<T>
Categories
(Core :: Graphics: Layers, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr52 | --- | unaffected |
firefox-esr60 | --- | wontfix |
firefox55 | --- | unaffected |
firefox56 | --- | disabled |
firefox57 | --- | fixed |
firefox65 | --- | wontfix |
firefox66 | --- | verified |
firefox67 | --- | verified |
People
(Reporter: ting, Assigned: sotaro)
References
Details
(Keywords: crash)
Crash Data
Attachments
(3 files, 1 obsolete file)
1.56 KB,
patch
|
rhunt
:
review+
|
Details | Diff | Splinter Review |
47 bytes,
text/x-phabricator-request
|
lizzard
:
approval-mozilla-beta+
|
Details | Review |
1.14 MB,
application/octet-stream
|
Details |
Comment 1•7 years ago
|
||
Updated•7 years ago
|
Comment 2•7 years ago
|
||
Comment 4•7 years ago
|
||
Comment 6•7 years ago
|
||
Comment 7•7 years ago
|
||
Reporter | ||
Updated•7 years ago
|
Updated•7 years ago
|
Comment 8•7 years ago
|
||
Comment 10•7 years ago
|
||
bugherder |
Updated•7 years ago
|
Comment 11•6 years ago
|
||
Comment 12•6 years ago
|
||
Issue still happening on Windows 10 Pro x86 with Fx 66.0b12
Crash report: https://crash-stats.mozilla.org/report/index/02cfe889-7660-49cb-900e-817de0190301
- Steps to reproduce:
- Launch Firefox
- Open Facebook and search for Poker Heat game
- Click to play game
-
Expected Results:
There are no issues encountered while using these apps. -
Actual Results:
The game remains in a loading state and after a while the tab crashes.
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Comment 13•6 years ago
|
||
Jessie, since it sounds like we have a way to reproduce this we should try to fix it. Maybe Sotaro would be good person to take a look?
Comment 14•6 years ago
|
||
Hey Sotaro - would you be able to take a peak at this?
Assignee | ||
Comment 16•6 years ago
•
|
||
All the remaining crashes seemed to happen under D3D11YCbCrImage::GetAsSourceSurface() and the GetAsSourceSurface() was called from BasicImageLayer::Paint() or LayoutUtils::SurfaceFromElement().
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 17•6 years ago
|
||
The almost all crash logs had the following GraphicsCriticalError logs. TDR seems to be related.
Could not get a DXGI adapter
A content-only TDR is detected
Detected device reset
Assignee | ||
Comment 18•6 years ago
|
||
If D3D11Device of D3D11YCbCrImage is already obsoleted by TDR, we should not use it.
Assignee | ||
Comment 19•6 years ago
|
||
Comment 20•6 years ago
|
||
Comment 21•6 years ago
|
||
bugherder |
Comment 22•6 years ago
|
||
the fix here is looking very contained - do you think we should still get it into firefox 66? if so, could you please request approval for uplift... thanks
Assignee | ||
Comment 23•6 years ago
|
||
Comment on attachment 9047925 [details]
Bug 1386487 - Check if D3D11Device is obsoleted in D3D11YCbCrImage::GetAsSourceSurface()
Beta/Release Uplift Approval Request
- Feature/Bug causing the regression: Bug 1223270
- User impact if declined: Tab could crash during playing a video when TDR happens.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: No
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): The patch just added ID3D11Device check.
- String changes made/needed: None
Updated•6 years ago
|
Comment 24•6 years ago
|
||
Comment on attachment 9047925 [details]
Bug 1386487 - Check if D3D11Device is obsoleted in D3D11YCbCrImage::GetAsSourceSurface()
Further fix for this top crash.
OK for uplift for beta 14.
Comment 25•6 years ago
|
||
bugherder uplift |
Updated•6 years ago
|
Updated•6 years ago
|
Comment 26•6 years ago
|
||
The issue is not reproducing anymore with 66.0b14 and latest 67.0a1 (2019-03-10) on Windows 10x32, however the tab crashes for OOM with this signature: https://crash-stats.mozilla.org/report/index/352f435c-33a5-4daa-b8f4-973940190311 using the steps from comment 12.
Sotaro Ikeda, any thoughts?
Assignee | ||
Comment 27•6 years ago
|
||
It seems like general oom at syle.
:emilio, can you comment to comment 26?
Comment 28•6 years ago
|
||
Yeah, it'd be interesting to get a memory report of that page on Windows and see if there's something going very wrong with style system memory usage (or somewhere else).
Gabi, is there any chance you could do that? Or somebody with a Win32 machine generally. Though maybe a memory report in win64 is enough to pinpoint the issue.
Comment 29•6 years ago
|
||
Hi Emilio,
Sorry to get back to you so late, I had some issues with the Windows machine on which the issue reproduces constantly.
I tried to get the memory dump file for the crash tab but I did not manage to create it in time to contain the relevant information. Can you give me some pointers or a tool that I can use?
Thank you
Updated•6 years ago
|
Comment 30•6 years ago
|
||
You can use about:memory
and save it, if you have time. Does the OOM always reproduce in the style system? or does it have different signatures?
Nick, do you know of a good way of finding out what's going on in a near-oom situation in Win32? In Linux I'd just use DMD or instrument the allocations in some other way but...
Comment 31•6 years ago
|
||
On Windows, Firefox periodically checks for low-memory conditions and will get a memory report if possible. If an OOM subsequently happens, the memory report will be included in the crash report. gsvelto may be able to add more details about this.
Also, DMD works on Windows, so you might be able to use it.
Comment 32•6 years ago
|
||
Comment 33•6 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #30)
You can use
about:memory
and save it, if you have time. Does the OOM always reproduce in the style system? or does it have different signatures?Nick, do you know of a good way of finding out what's going on in a near-oom situation in Win32? In Linux I'd just use DMD or instrument the allocations in some other way but...
While trying to reproduce the oom crash and save the memory report, tab crashed again with CContext::ID3D11DeviceContext1_Map_<T> signature on latest beta 67.0b6 on Windows 10x32. Added the memory report json.
Comment 34•6 years ago
|
||
The memory report looks entirely normal to me. I don't see anything in there that would indicate an OOM is likely to occur.
Comment 35•6 years ago
|
||
Here two new reports for the [@ OOM | small ] crash:
- https://crash-stats.mozilla.org/report/index/caa5f36b-04dd-4d33-9128-0a3ac0190404
- https://crash-stats.mozilla.org/report/index/accc1656-fb32-4aa3-b385-e39890190404
Crashes occurred with same steps under Windows 10x32 on beta 67.0b7.
Comment 36•6 years ago
|
||
Ah, then I wouldn't worry about it, those stacks are different and the page is probably just requesting too much data for Win32 to process... I'm not particularly concerned as long as the OOM doesn't happen consistently in one place.
Comment 37•6 years ago
|
||
After looking at the Mozilla Crash Reports, there isn't a significant number of crashes for "CContext::ID3D11DeviceContext1_Map_<T>" signature on the latest Firefox builds and based on the above comment concerning the OOM crash I'm setting this issue on verified as fixed.
Description
•