C++ access violation reading location

Started by
4 comments, last by edes 4 years, 7 months ago

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

Advertisement

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.]

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? 

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.)

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!

This topic is closed to new replies.

Advertisement