Jump to content
  • Advertisement
Sign in to follow this  
Funkymunky

Vulkan Debugging this Vulkan crash

This topic is 993 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

So I've slowly been throwing together a vulkan example so that I can get an understanding of how everything works.  Right now I get an access violation, and what I'm really wondering is if anyone has any suggestions on how to debug it.

 

I've read through SaschaWillems' code, and I thought I'd done everything he did (I've also compared it against the demo code that comes with the Lunar SDK, and everything seems in order).  But I get a crash when I call vkQueuePresentKHR, with the error being "Access violation reading location 0xBAADF00D".  So that's an interesting hex value, and googling it reveals that it's generally "used by Microsoft's LocalAlloc to indicate uninitialized allocated heap memory".  In my debugger (Visual Studio 2015), it pops open a window that says "No symbols loaded" and is looking for VkLayer_swapchain.dll.

 

 If I disable that call to vkQueuePresentKHR, the program will run (and obviously not display anything), but will crash on VkDestroySurfaceKHR, with an Access Violation at 0xBAADF025.  The combination of these crashes makes it seem like my surface is uninitialized, but I've walked through that code several times and everything seems in order.  I have checks for VK_SUCCESS on every vulkan function and nothing is failing or indicating an error.

 

So I'm not really looking to dump my Vulkan test code here, as it's a lot, and I'm not sure exactly where the issue is yet.  Really what I'm wondering is if anyone has any tips on debugging this problem.  Maybe a better way to look into VkLayer_swapchain.dll?

Share this post


Link to post
Share on other sites
Advertisement
Check the parameters you pass to vkQueuePresentKHR(). The second pointer in particular might have fields on it which are uninitialized. Check in the debugger, walk through all the pointers you can find that you are passing (either directly or indirectly) into that API.

Share this post


Link to post
Share on other sites

 

So I'm not really looking to dump my Vulkan test code here, as it's a lot, and I'm not sure exactly where the issue is yet.  Really what I'm wondering is if anyone has any tips on debugging this problem.  Maybe a better way to look into VkLayer_swapchain.dll?

 

 

The SDK actually ships with the debug versions of the validation layers in the Source\lib folders. The docs say:

 

Visual Studio 2015 is not officially supported, but can be used to build the demos and samples projects. Using Visual Studio 2015, however, only allows you to run the demos and samples if you use the Release version of the loader and layers.

Attempting to use the Debug versions of the SDK loader or layers (which have been built with VS 2013) will fail on loading MSVCR120.dll. This is because that DLL is a debug DLL shipped only with VS 2013.

 

So if you have VS 2013 or the VS 2013 redistributable package installed stepping into the validation layers should still work when you point VS2015 at the right .pdb and source files. I had to replace the release version dlls in the Bin fold with the debug ones to make them load, not sure if there is a better way.

If there is a problem with using the VS 2013 binaries with VS 2015 you could also build the debug layers yourself, but I have not tried that yet... https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/blob/master/BUILD.md

 

Share this post


Link to post
Share on other sites

Eternal, that is a great help.  Copying those dlls and pointing the compiler to the appropriate .pdb file lets me see what the specific error is.

 

It's a crash in the aforementioned vkQueuePresentKHR function.  The code crashes at:

 

                                   if ((pSurface->numQueueFamilyIndexSupport >
                                         queueFamilyIndex) &&
                                        (!pSurface->pQueueFamilyIndexSupport
                                              [queueFamilyIndex])) {
 
The problem is that pSurface->pQueueFamilyIndexSupport is not an initialized value.  pSurface->numQueueFamilyIndexSupport is 3452816845, which allows this decision to access pQueueFamilyIndexSupport even though it's not valid.
 
This decision is to check if the surface is supported for present operations.  I believe I've followed the code identically to find a queue that supports both graphics operations and present.  I don't understand why numQueueFamilyIndexSupport is such a big value.  When creating the swapchain, I set the queueFamilyIndexCount and pQueueFamilyIndices fields of the VkSwapchainCreateInfoKHR structure to 0 and nullptr respectively.

Share this post


Link to post
Share on other sites
Your number is equal to 0xCDCDCDCD, which is a debugger poison value used to indicate that you allocated memory but did not initialize it. I'm guessing this a straightforward case of user error in that you don't init a member that you're supposed to.

Share this post


Link to post
Share on other sites

After finally circling back to this, I discovered that the problem was that when creating the VkInstance, I was only using the extension "VK_KHR_SURFACE_EXTENSION_NAME."  As I am doing this on Windows, I needed "VK_KHR_WIN32_SURFACE_EXTENSION_NAME."

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!