protonscr

D3D9: Multithreaded Texture creation may crash

dxvkclosed bugd3d9
doitsujin/dxvk#4613 · opened 2025-01-14 by enginelesscc · updated 2025-02-17 · 6 comments · github
1 matching comments, n / p to jump
Eenginelesscc 2025-01-14 github

Hi,

I was curious if i could apply dxvk on my d3d9 project and came across one issue:

I create my d3d9ex device with multithreaded flag and use it to load my assets in a separate thread.

And this is where DXVK seems to have its issue:

AV: Exception thrown at 0x67FC3BDC (d3d9.dll) in project.exe: 0xC0000005: Access violation writing location 0x00000000.


[Inline Frame] d3d9.dll!dxvk::D3D9MemoryChunk::Unmap(dxvk::D3D9Memory *) Line 157	C++
d3d9.dll!dxvk::D3D9Memory::Unmap() Line 285	C++
[Inline Frame] d3d9.dll!dxvk::D3D9CommonTexture::UnmapData() Line 238	C++
d3d9.dll!dxvk::D3D9Initializer::InitTexture(dxvk::D3D9CommonTexture * pTexture, void * pInitialData) Line 63	C++
d3d9.dll!dxvk::D3D9DeviceEx::CreateTexture(unsigned int Width, unsigned int Height, unsigned int Levels, unsigned long Usage, _D3DFORMAT Format, _D3DPOOL Pool, IDirect3DTexture9 * * ppTexture, void * * pSharedHandle) Line 663	C++
d3dx9_43.dll!_D3DXLoadVolumeFromResourceW@36()	Unknown
d3dx9_43.dll!_D3DXCreateTextureFromFileInMemoryEx@60()	Unknown

Looking at the assembly at the eip of the exception, it seems to out-of-bounds the m_mappingRanges vector.
In my case it seems to access index 0, but the vector is empty.

Likely a race condition as it may work at some times and other times not.

Throwing all work onto a single thread solves this and dxvk works just fine then.

Software information

AMD64 Windows 24H2 26100.2605, 32bit application

System information

  • GPU: RTX 4090
  • Driver: 566.45
  • Wine version: n/a
  • DXVK version: 32bit 2.5.3*(*)

*windows-msvc CI: dxvk-merge-69a3d78b3435c39caf561ea71778ae6be0e9f44b-msvc-output
**This bug also appears on older versions

Apitrace file(s)

/

Log files

/

BBlisto91 2025-01-14 github

What is the oldest dxvk you have tested?

Edit: Is just curious if it is because of the 32bit d3d9 memory management that was implemented in 2.0 from the error (i am not a dev)

Eenginelesscc 2025-01-14 github

What is the oldest dxvk you have tested?

Looking at my history it were 2.0/2.1

BBlisto91 2025-01-14 github

Does it work if you make a dxvk.conf file next to the exe an insert d3d9.textureMemory = 0 ?
You can check in the dxvk log if it was picked up

KK0bin maintainer 2025-01-14 github

I took a look at it again and I did find a race in the D3D9 mapped file memory code. I'll fix that over the next few days. Hopefully that will fix your crashes.

Eenginelesscc 2025-02-03 github

I may have encountered another possible race (occurred outside mainthread):

dxvk::DxvkBuffer::assignStorage ~ m_bufferInfo = m_storage->getBufferInfo();

mov eax, [edx+30h]
----------^^^ = nullptr  (m_storage, slice?)

https://github.com/doitsujin/dxvk/blob/master/src/dxvk/dxvk_buffer.h#L345

backtrace:

dxvk::DxvkBuffer::DxvkBuffer
dxvk::DxvkDevice::createBuffer
dxvk::D3D9CommonTexture::CreateBuffer
dxvk::D3D9DeviceEx::LockImage
dxvk::D3D9Surface::LockRect
dxvk::D3D9Texture2D::LockRect

Seems to be more rare, cannot easily reproduce :/

KK0bin maintainer 2025-02-03 github

This one is odd. The internals of DxvkBuffer are only changed on the CS-Thread or in the constructor of DxvkBuffer. And the constructor calls are additionally also protected by the D3D9 device lock on top of that. Only once the constructor is done it gets handed over to the CS thread.

DLLs

Error codes