DebugCallback::new does not check for null pMessageIdName or pMessage

[zphixon]

Neither DebugCallback::new nor CStr::from_ptr check for a null pointer which can lead to crashes. The RenderDoc bug reports have been resolved, as this is unrelated to RenderDoc. The remainder of this post is irrelevant.

---

The latest version of Vulkano crashes when I attempt to use RenderDoc by injecting into a running process.

• Version of vulkano: 0.17
• OS: Windows 10
• GPU (the selected PhysicalDevice): Radeon RX 580
• GPU Driver: Driver Version 19.50.15.01-200117a1-351300C-RadeonSoftwareAdrenalin2020

This short program creates the following output:

    Finished dev [unoptimized + debuginfo] target(s) in 0.09s
     Running `target\debug\crashes_on_my_machine.exe`
Press enter...
Using physical device (DiscreteGpu): Radeon RX 580 Series
error: process didn't exit successfully: `target\debug\crashes_on_my_machine.exe` (exit code: 0xc0000005, STATUS_ACCESS_VIOLATION)

The example program was essentially copy-pasted from the examples in this repository, with which I've also been able to reproduce this behavior.

To reproduce:

• cargo run the program
• In RenderDoc, File -> Inject into Process
• Select crashes_on_my_machine.exe and press inject
• Press enter in the console window to begin Vulkan calls

~~Through some println debugging, I've narrowed it down to possibly this macro instantiation in vk-sys to generate bindings for vkCreateDevice, where anything after this line is unreachable.~~ see new comment

I've spoken with Baldur Karlsson via email about a bug report with the same conditions as the example program above, wherein he stated it's possible this is a driver bug. The report indicates possible interference with RivaTuner but I've verified that the behavior occurs with or without RivaTuner. Another bug report I filed pointed to a crash due to strlen in ucrtbase.dll which I believe is related. I can't say for sure since all of this is way over my head anyway 😬

I also have the rdoc-generated .dmp file for this sample program in the repo. I tried out windbg and I didn't really understand what I was doing, but the output from messing around with the minidump is there as well if it's useful.

[zphixon]

It was pointed out to me that RTSS was still active when I ran into some of this behavior. I've updated the windbg output and it pointed me to one of CStr::from_ptr here in DebugCallback::new.

I found that by commenting out the sample program's DebugCallback::new call, the sample program would operate normally.

[marc0246]

I'm unsure what exactly this is referencing, but I can only image the callback extern function was meant, in which pMessageIdName was dereferenced without checking for null. This bug has since been fixed in #1878.

[marc0246]

Actually it was #1487 that fixed the bug, oopsie.