Jump to content

  • Log In with Google      Sign In   
  • Create Account

xnamath access violation because of std::string variable


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
24 replies to this topic

#21 Zaoshi Kaba   Crossbones+   -  Reputation: 4574

Like
0Likes
Like

Posted 06 January 2013 - 07:14 AM

and am not sure how am suppose to check the buffer memory location.
so I just took a screenshot >.<
am guessing its nots aligned as there are alot of things that ends with 8 XD
http://imgur.com/eucRH
and this second picture is how it looks like when it does work (by undeclare the string)
http://imgur.com/fyfYs
You are right.
As you can see in first screenshot address of cBufferObject.WVP.r is 0x00c45998 which means it's not aligned.
While in second screenshot it's 0x01de5950 so it is aligned and doesn't crash.

Now you just need to figure which new call to fix, or use special functions to load/unload unaligned data into local variables.

Edited by Zaoshi Kaba, 06 January 2013 - 07:17 AM.


Sponsor:

#22 yckx   Prime Members   -  Reputation: 1291

Like
0Likes
Like

Posted 06 January 2013 - 07:38 AM

You're not using new, but you're using smart_ptr, so it's still dynamic memory allocation.

 

 

 

I did some googling and found a page that indicates that Microsoft's implementation of shared_ptr correctly aligns its objects. I also found a 2010 post that said that there was posts known issue with boost::make_shared() such that it did not align dynamically created objects, although explicitly constructing a boost::shared_ptr would properly align the dynamically created object.

 

 

 

So i would try calling shared_ptr() instead of make_shared().



#23 Conny14156   Members   -  Reputation: 270

Like
0Likes
Like

Posted 06 January 2013 - 08:05 AM


and am not sure how am suppose to check the buffer memory location.
so I just took a screenshot >.<
am guessing its nots aligned as there are alot of things that ends with 8 XD
http://imgur.com/eucRH
and this second picture is how it looks like when it does work (by undeclare the string)
http://imgur.com/fyfYs
You are right.
As you can see in first screenshot address of cBufferObject.WVP.r is 0x00c45998 which means it's not aligned.
While in second screenshot it's 0x01de5950 so it is aligned and doesn't crash.

Now you just need to figure which new call to fix, or use special functions to load/unload unaligned data into local variables.

 

Now for the most retard question of the year,

how can commeting/uncommeting a std::string change my buffer into a 16 bit or not? while those two doesnt even have anything to do with each other for now

You're not using new, but you're using smart_ptr, so it's still dynamic memory allocation.

 

 

 

I did some googling and found a page that indicates that Microsoft's implementation of shared_ptr correctly aligns its objects. I also found a 2010 post that said that there was posts known issue with boost::make_shared() such that it did not align dynamically created objects, although explicitly constructing a boost::shared_ptr would properly align the dynamically created object.

 

 

 

So i would try calling shared_ptr() instead of make_shared().

If I try to call shared_ptr it doesn't want to properly work, Its doesnt seem it want to return the component correctly so when I try to add it its complain its empty sad.png

 

 

 

 

 

Edit:
I solved it now I think for good.

I removed every xmmatrix and replaced it with XMFLOAT4x4 and I just use xmstore and xmload to transfer the values.



#24 Zaoshi Kaba   Crossbones+   -  Reputation: 4574

Like
0Likes
Like

Posted 06 January 2013 - 12:54 PM

how can commeting/uncommeting a std::string change my buffer into a 16 bit or not? while those two doesnt even have anything to do with each other for now

Most likely just a coincidence, unless Windows makes difference based on requested memory size and allocates it at different place.



#25 yckx   Prime Members   -  Reputation: 1291

Like
0Likes
Like

Posted 06 January 2013 - 03:31 PM

They're both members of the same class, and class members are laid out in the order in which they're declared in the class definition. So commenting out the std::string changed where the XMMATRIX was being placed in relation to the beginning of the object.

 

Edit: And the issue has been avoided rather than corrected, so i don't believe the solved tag is warranted, and may mislead others.


Edited by yckx, 06 January 2013 - 03:35 PM.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS