Memory Corruption

Started by
7 comments, last by AxeGuywithanAxe 7 years, 5 months ago

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.

Advertisement

Only one word needed: valgrind

Hahah Alberth before I open the topic I was thinking to write word by word the exact same thing ... wow

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.

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.

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

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);
}




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?

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.

This topic is closed to new replies.

Advertisement