Public Group

# C++ access violation reading location

## Recommended Posts

Here's my issue: When I set visual studio to release mode, i get an access violation exception when trying to call one of Vulkan's vkCreate functions. I've read around, and I'm guessing that the problem is caused by uninitialized variables. However, I have very few variables and they all seem to have a valid memory location. Am I misunderstanding a valid memory location as a default-initialized variable? Here's a screenshot to accomodate what I'm trying to explain: screenshot.

On the right, you can see the console output of the two std::cout I put in for debugging. I dereference the variables to get their memory location, and they clearly exist. However, when I call the function, it's as if I am dereferencing a null pointer. What could this be caused by?

On debug mode, I have a different issue (and it's probably of the same kind), since it's also an access violation reading some memory location. I think understanding why the release mode bug happens will help me fix the other one, too. I'm just very lost, because I don't even know what to google (googling the exception didn't net any results).

here's what i think is the most relevant code: https://pastebin.com/gYBxtYzz (since my code is already quite large)

you can see how i initialize the m_instance in the header part, the constructor in the .cpp part and then the actual problematic function is at the very bottom of the .cpp part

edit: the reason i post here is because it has little to do with vulkan and a lot to do with my misunderstanding of c++, im guessing i am making a basic mistake somewhere in my code

Edited by edes

##### Share on other sites

Can you post the code for getExtensions()? (Or is that third-party code?) Also, it looks like ppEnabledExtensionNames might end up being a dangling pointer.

[Edit: The pointer thing may not be an issue given that the vector is still in scope when the function is called, but it'd probably still be useful to know what getExtensions() is doing exactly. It might also be useful to  know what Debug::validationLayers.data() does, and also whether ENABLE_VALIDATION is enabled or not.]

Edited by Zakwayda

##### Share on other sites
Quote


#ifdef ENABLE_VALIDATION
createInfo.enabledLayerCount = Debug::validationLayers.size();
createInfo.ppEnabledLayerNames = Debug::validationLayers.data();
#else
createInfo.enabledLayerCount = 0;
createInfo.ppEnabledExtensionNames = nullptr;
#endif

The "else" block here refers to a different pair variables than in the "if" block.  Was this intended?

##### Share on other sites

I think you can forget what I asked about before  If ENABLE_VALIDATION is not defined, then what fastcall22 observed seems like a likely culprit. (I will mention more generally though that you might double-check all your code paths to make sure all necessary fields of the createInfo object are filled out no matter what. It might also be useful to log or examine in the debugger not only &createInfo, but also the relevant fields of createInfo itself to make sure they have the values you expect them to.)

##### Share on other sites
6 hours ago, fastcall22 said:

The "else" block here refers to a different pair variables than in the "if" block.  Was this intended?

no, it was not intended, and it fixed this specific issue! it seems like it was just one of those missing-colon type mistakes after all. thank you!

• ### Game Developer Survey

We are looking for qualified game developers to participate in a 10-minute online survey. Qualified participants will be offered a \$15 incentive for your time and insights. Click here to start!

• 11
• 23
• 38
• 16
• 75