Sign in to follow this  

Custom Memory Allocations and memory allocation

This topic is 402 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

Hey guys, so I seem to be having this issue with memory allocation. I am using a large linear allocator, and in 9 out of 10 cases it works perfectly, but for some reason, when I allocate a class I get a memory access violation when initializing a few of the variables in the constructor. if I allocate sizeof(T) + 1, then I don't have an access violation, I've been stuck on this for a while, and any suggestions would help.

Share this post


Link to post
Share on other sites

I've tried that also, and it doesn't work. For testing purposes, I wrote code like such : 


//allocate a memory block 
static uint8* GAllocator = new uint8[1024*1024];

CRenderView* AllocateView()
{
    return new(GAllocator)CRenderView();
}


void Main()
{
  auto* RenderView = AllocateView();
}

the access violation occurs in the constructor. As of now I'm guessing i'm having some major memory corruption somewhere in the application, but can't seem to figure out where.

Share this post


Link to post
Share on other sites

Well, I've moved the code to different sections of my project so there isn't a specific call stack that works and doesn't work. I'm not quite sure what the issue may be, I don't think it can be an issue of allocating over dll lines, because I have 5 other dlls that never suffer this issue. It is specifically this class alone that has an issue, and I can't seem to decipher what's different.

Share this post


Link to post
Share on other sites

It is specifically this class alone that has an issue

You probably need to share some code from its constructor then.
Somehow, it's trying to read data from (T*)-1... Which could be as simple as there being a member variable that's a pointer, which is read from before it's initialized.

 

I find that when making a custom allocator, it's a good idea to memset the returned allocations to something like 0xcd / etc in non-shipping builds, as this will make these kinds of "read from uninitialized pointer" bugs show up as "Access violation reading from 0xcdcdcdcdcdcdcdcd" as well as making uninitialized variables stand out like a sore thumb in the debugging watch windows or memory view.

Share this post


Link to post
Share on other sites

Yeah, i tried changing the memory allocated with "0xcd" and it still returned "0xFFFFFFFFF", that's why I'm so confused about where this issue is coming from. Below is the code,

and it breaks after "Matrix.ExtractLeftPlane(....)" , I tried changing around the order of extraction, but it doesn't seem to matter, it always causes an access violation after the second call to "ExtractXXXPlane" whether it's "ExtractFarPlane" or "ExtractLeftPlane", and etc... if I remove the "m_ViewFrustum.Init" from my code base, my code runs perfectly.

 

Share this post


Link to post
Share on other sites

if I remove the "m_ViewFrustum.Init" from my code base, my code runs perfectly

 

Are you sure you have the problem in allocater rather than your matrix bake or frustum init function?

Could you access the baked matrices correctly?

 

What may help is if you create a dump from your class and look if anything is located correctly in the memory you are operating on

Share this post


Link to post
Share on other sites

Whenever I see words like "matrix" and "plane" together with "access violation", my first thought is: "unaligned SSE load".

Sure this is not the case? Sure that your allocator indeed properly aligns to 16-byte bounds? If it allocates like in your above code snippet (new uint8_t[some_number]) then this is practically guaranteed not to be the case.

Note that new T[n] usually works something like this:

  • Calculate n*sizeof(T), and add a small constant (usually something like sizeof(size_t), but could be something different)
  • Call malloc, and ask for a block of that size.
  • malloc will usually (not guaranteed, but usually) keep blocks that are something like 16-byte aligned or such for technical reasons. It will write the allocation size and maybe some other metadata into the first few bytes, and return a pointer to the location immediately after that. When you call free, it subtracts the metadata's size from the address, and thus knows how to handle this deallocation. That, however, means that the address coming from malloc already has a rather low chance of being properly aligned.
  • Write the array size into that address, increment the pointer again, and return that address. Why? C++ must know how many destructors to call when you invoke delete[], thus it must store the size of the array somewhere. The most straightforward way is, of course, to store it right there. That's another 4 or 8 byte offset. Which might accidentially align the beginning of your data block again, but usually won't.

(I'm assuming that the class itself doesn't contain mis-aligning things such as a single integer or the like in the middle... in that case it should [i]never[/i] work, not just when the allocator is used).

Share this post


Link to post
Share on other sites

This topic is 402 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this