protonscr

Shutdown crash after storing private references to context shaders

dxvkclosed d3d11
doitsujin/dxvk#3169 · opened 2023-01-05 by rlocatti-nv · updated 2023-01-07 · 2 comments · github
1 matching comments, n / p to jump
Rrlocatti-nv 2023-01-05 github

Starting with commit 8758bcedae4cd95827acb801be0aba2ae3edc3f1 a few applications started crashing on shutdown inside RtlAcquireSRWLockExclusive. Reverting this commit fixes the issue.

Here is a backtrace of the crash:

 	ntdll.dll!RtlAcquireSRWLockExclusive()	Unknown
>	[Inline Frame] d3d11.dll!dxvk::mutex::lock() Line 182	C++
 	[Inline Frame] d3d11.dll!std::lock_guard<dxvk::mutex>::{ctor}(dxvk::mutex &) Line 427	C++
 	[Inline Frame] d3d11.dll!dxvk::DxvkMemoryAllocator::free(const dxvk::DxvkMemory &) Line 443	C++
 	d3d11.dll!dxvk::DxvkMemory::free() Line 56	C++
 	d3d11.dll!dxvk::DxvkMemory::~DxvkMemory() Line 50	C++
 	d3d11.dll!dxvk::DxvkImage::`scalar deleting destructor'(unsigned int)	C++
 	[Inline Frame] d3d11.dll!dxvk::D3D11Texture2D::{dtor}() Line 1175	C++
 	d3d11.dll!dxvk::D3D11Texture2D::`scalar deleting destructor'(unsigned int)	C++
 	[Inline Frame] d3d11.dll!dxvk::ComObject<ID3D11Texture2D1>::ReleasePrivate() Line 67	C++
 	d3d11.dll!dxvk::D3D11Texture2D::Release() Line 1203	C++
 	Ashes_DX11.exe!...()	Unknown

Software information

Reproduced on an internal Ashes of the Singularity frame capture. It also happens on other titles.
I can try reproducing it in a real application if the bug is not obvious.

System information

  • GPU: NVIDIA GeForce RTX 3060 Ti
  • Driver: 527.56.0
  • Wine version: Windows 11
  • DXVK version: f94b42f23f34cc92c9115764f800292e6d7a2c50

Log files

BBlisto91 2023-01-05 github

Hello.
If possible could you attempt to record a apitrace of a section of the game where it usually crashes? Do it without dxvk.
https://github.com/doitsujin/dxvk/wiki/Using-Apitrace

If not then i will try to test the game myself on Linux tomorrow.

Edit: oh didn't notice it was you Rodrigo 😁

Ddoitsujin maintainer 2023-01-05 github

The reason why we don't crash without that commit is most likely because we're straight-up leaking the D3D11 device.

What exactly is happening anyway? This sounds like the underlying DXVK device already got destroyed by the time the texture gets destroyed (which however should hold a strong reference to the D3D11 device), so this should be impossible, not sure what to make of this.

Either way, yes, COM reference counting is known to be extremely broken in DXVK, but it's also extremely hard to get right.

DLLs