Sign in to follow this  

Memory Corruption

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, so some of you may have seen my post yesterday, I'm fairly sure I am dealing with a memory corruption issue, and I wanted to ask if anyone knew of any good strategies to pin it down.. my code base is quite large and i'd rather not leave any more holes in my wall.

Edited by Kylotan
added link to the post in question

Share this post


Link to post
Share on other sites

If you are on Windows are there some tools that would do a similar job to Valgrind, such as Visual Leak Detector for Visual Studio or Dr Memory (never used it, just heard of its name). Although personally, I like to use Valgrind.

Share this post


Link to post
Share on other sites

In your case it seemed to be quite reproducible and also linked to the use of your own allocator. I'd follow 2 strategies here:

 

1. extensive pre- and post- condition checking in the most obviously affected functions. This can be your own code (check the this pointer looks legit, verify that any magic numbers/canaries haven't been broken) and OS-provided helpers (stuff like AfxCheckMemory). For example, you say "if I remove the "m_ViewFrustum.Init" from my code base, my code runs perfectly." - so you need to run tests directly after m_ViewFrustum.Init to see what's changed, and ideally you'd have checks inside the Init function. You will also want to ensure the CFrustrum object has a complete and correct constructor.

 

2. Strip back the use of that allocator. It is probably hiding a bug somewhere which you'd find sooner if each allocation was made separately. If removing it entirely isn't an option, change its behaviour to make it more predictable.

Share this post


Link to post
Share on other sites

In your case it seemed to be quite reproducible

Yeah, in this  particular case you just need to practice using the standard debugging tools to pinpoint the crash first. Then if the crash is due to corruption, then go looking for it. 

 

In your case where a particular constructor is crashing, step into that constructor line by line, and at each step validate that the values of its member variables, locals, arguments, etc line up with the expectations of the program. Look at the address that's being passed into ExtractLeftPlane and check if it's valid. As that function writes to pointers, check the values of the pointers beforehand. Find out exactly how it's ending up attempting to write to -1 -- the debugger will tell you if you watch closely and step line by line until the crash. Once you know the exact mechanism, you can identify the candidate for corruption, but not beforehand.
 
As for the general question, On windows I use microsoft application verifier and configure it to allocate non-accessible pages immediately before/after every allocation, which causes most out of bounds writes to immediately crash instead of silently causing memory corruption.
I can't find a good link on it right now, but this mentions similar things: http://stackoverflow.com/questions/1010106/how-to-debug-heap-corruption-errors

Share this post


Link to post
Share on other sites

Thank you all for your responses. As of right now the bug isn't in my constructor, but is now later in the program when i'm freeing memory via _aligned_free. So the problem is starting to affect other parts of my code. If someone could look at my code, that would be greatly appreciated. I can't seem to decipher the potential bug in my code.


class CLinearAllocator
{
public:
  CLinearAllocator(uint8* Memory, int32 Size):
   AllocatorMemory(Memory),
   DataSize(Size),
   Top(Memory),
   End(nullptr)
   {
     End = Memory + Size;
   }

  void* Allocate(int32 Size)
  {
      uint8* Result = Top;
      uint8* NewTop = Top + Size;
      //out of memory, this is never reached
      if(NewTop > End)
      {
        return nullptr;
      }
      Top = NewTop;
     return Result;
  }



uint8* Top;
uint8* End;
uint8* AllocatorMemory;
int32  DataSize;

};


void* operator new(size_t Size)
{ 
   return GLinearAllocator.Allocate(Size);
}




Share this post


Link to post
Share on other sites

You're not showing where, or when, GLinearAllocator is constructed.

 

(Also, why is _aligned_free being called? Isn't this memory you're just pulling out of a static buffer?)

 

Oh... and where is your delete operator?

Edited by Kylotan

Share this post


Link to post
Share on other sites

Sigh... thank you all for your help.. it was definitely my allocator. I reworked the implementation and forgot to reset a value so there was an overflow.


To answer your questions Kylontan, _aligned_free was being called by one of my Arrays, it has nothing to do with the allocator, there was just a large buffer overflow, from not reseting. Thank you all for our help.

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