[6f694260] Crash at map start with Vulkan

[vsonnier]

Hi Graf and all, I just noticed that on the most recent master (post 4.8) the mod I play with, Brutal Doom Black Edition (https://www.moddb.com/mods/brutal-doom/ ... ck-edition) crashes at startup
with a message "Could not create vulkan image: initialization failed".

It works without any mod loaded of course. I quickly reduced the scope to the fact that the mod is playing a TITLEMAP at startup.

So here it is: as a minimal reproducer, it contains only the MAPS/TITLEMAP.wad from the original mod. All the resources are absent but it doesn't prevent the titlemap from loading properly (in 4.8) or crashing (in master).

I hope it is enough to investigate.

BTW, congrats for v4.8 !

Edit : starts crashing at commit 40872a2b

Regards,

Vincent

Update : Has nothing to do with TITLEMAP, see below, so I updated the title. Removed the linked file.

[Graf Zahl]

You have to post your INI. I can't get it to crash so it must be some PP element combination I did not think of.

[vsonnier]

You are right, I investigated further, and it turns out it has nothing to do with a TITLEMAP, it crashes simply at loading a simple DOOM2 MAP01.

Since the TITLEMAP was automatically played, that was the first thing I saw

I likely resolves around my particular Vulkan configuration, because:
- Fresh generated gzdoom-user.ini : OK for Vulkan, OK for OpenGL (backend selected at startup dialog)
- My gzdoom-Crash.ini with my particular settings : crash for Vulkan, OK for OpenGL (backend selected at startup dialog)

So somewhere my additional settings trigger the problem.

For what it is worth, I've reproduced the problem runing in VS 2022 x64 in a Debug configuration. It crashs at the same place whatever I force execution on HD 630 or Geforce 1050 Ti (Mobile) so it looks universal (for me)

Here is the error and trace :

Code: Select all

Exception thrown at 0x00007FF81E85FA12 (nvoglv64.dll) in gzdoom.exe: 0xC0000005: Access violation reading location 0x000001ED98EAA8C0.
in vk_objects.h (917):
 
nvoglv64.dll!00007ff81e85fa12()	Unknown
 	nvoglv64.dll!00007ff81e85a3d5()	Unknown
>	gzdoom.exe!VulkanDescriptorSet::~VulkanDescriptorSet() Line 917	C++
 	[External Code]	
 	gzdoom.exe!VkMaterial::DeleteDescriptors() Line 366	C++
 	gzdoom.exe!VkMaterial::~VkMaterial() Line 351	C++
 	[External Code]	
 	gzdoom.exe!FGameTexture::~FGameTexture() Line 108	C++
 	[External Code]	
 	gzdoom.exe!FTextureManager::DeleteAll() Line 91	C++
 	gzdoom.exe!D_Cleanup() Line 3753	C++
 	gzdoom.exe!GameMain() Line 3689	C++
 	gzdoom.exe!DoMain(HINSTANCE__ * hInstance) Line 269	C++
 	gzdoom.exe!wWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * nothing, wchar_t * cmdline, int nCmdShow) Line 557	C++
 	[External Code]	

[dpJudas]

Based on that call stack it is most likely deleting a descriptor set still in use by the GPU. VkMaterial's internals should probably stop having its lifetime directly tied the hwrenderer objects as time has shown those get created and deleted in situations that aren't that easy to predict and manage for the backend. I'll try do something about that in my next update of the backend.

[Player701]

g4.8pre-501-geb56eb380 soft-crashes for me too when trying to load a level:

Code: Select all

Execution could not continue.
Could not create vulkan image: initialization failed

If I have a debugger attached, it produces a stack trace similar to vsonnier's (only with different offsets in nvogl64.dll) upon closing the game window.

INI file attached.

[Graf Zahl]

I reverted the commit that caused it - I was just trying to get rid of a poor data setup, but there seem to be some hidden dependencies in the Vulkan backend that are not immediately obvious.
The texture manager will eventually have to be rewritten once OpenGL is gone to better accomodate Vulkan's needs.