How to find memory corruption?

This is a discussion on How to find memory corruption? within the C++ Programming forums, part of the General Programming Boards category; Hi, I've several processes linking/accessing a single DLL. On some point in time something seems to occur that overwrites wrong ...

  1. #1
    Registered User
    Join Date
    Nov 2006
    Posts
    519

    How to find memory corruption?

    Hi,

    I've several processes linking/accessing a single DLL.
    On some point in time something seems to occur that overwrites wrong part of memory. It seems some part of the DLL's memory gets corrupted which is the worst thing, because so I don't even have a clue which process behaves badly.

    Do you have any ideas/strategies how to find the bug, given that boundchecker programs are to expensive and probably also to slow?

    Thank you in advance!

  2. #2
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    A few methods I've used:

    Identify the culprit by looking at the data: Try to analyze what the content of the memory is - does it contain pointers, if so, what are those pointers pointing to? Does it contain some known data of some other type (text strings, floating point numbers, etc).

    Build your own "overstepping the line" detection: Modify the malloc/free or new/delete to "overallocate" by some amount and fill with a pattern, and keep a list of known allocations. Every so often (e.g. every N allocations/frees), scan the list to see that your "overstep clay" is intact. If you store who allocated the memory (file and line), then you can usually figure out who the culprit is from that. "keeping" a list of "deleted memory", which is filled with a pattern to identify usage of freed memory is also a good idea. You can make that a circular buffer/FIFO, so you keep the last 256 or something allocations, and remove the oldest when the list is full.

    Add extra checking for out of bounds: Guess [perhaps using one of the two methods above] where the fault is and add code to check for out of bounds access to memory. Add NULL-pointer assignment whenever something is deleted that doesn't also go out of scope immediately.

    Code review: Again, this method works best if you already have a good idea of where in the code it goes wrong. Have a friend/colleague sit next to you, whilst you explain what the code does. Explaining to someone else forces you to look more at the code, so it usually goes something like this: "And here I do this, and then we check that X is greater than Y - Ah, hang on a bit - we should check that X is greater than or EQUAL to Y."

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  3. #3
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,001
    Quote Originally Posted by matsp View Post
    Build your own "overstepping the line" detection: Modify the malloc/free or new/delete to "overallocate" by some amount and fill with a pattern, and keep a list of known allocations. Every so often (e.g. every N allocations/frees), scan the list to see that your "overstep clay" is intact. If you store who allocated the memory (file and line), then you can usually figure out who the culprit is from that. "keeping" a list of "deleted memory", which is filled with a pattern to identify usage of freed memory is also a good idea. You can make that a circular buffer/FIFO, so you keep the last 256 or something allocations, and remove the oldest when the list is full.

    Add extra checking for out of bounds: Guess [perhaps using one of the two methods above] where the fault is and add code to check for out of bounds access to memory. Add NULL-pointer assignment whenever something is deleted that doesn't also go out of scope immediately.
    This is usually already done by Visual C++ / Visual Studio, so you can save time and energy by using its debugger for that.
    Another very useful method I find is data breakpoints (VC supports 'em). Basically, you can set breakpoints so the debugger breaks when a certain memory location is changed or written to.

    Say, for example, you get an access violation. The pointer is not NULL. That means it's either free or pointing somewhere it shouldn't.
    Then identify the variable. If it's local, then it's probably a bug in the function. Just use stepping and see if it isn't a bigger problem.
    If it's isn't local, or if the local variable gets some value from some other non-local variable (if it's a linked list or such), then use a data breakpoint.
    You can try to have the debugger break when it writes the current value of the pointer to the pointer. If you replicate the exact situation, it might just work.
    Otherwise you may have to track down everytime it changes. You can also add to allow it to break after the pointer has been modified X times. It's useful when you know a little more about the time frame when the bug occurs, so you don't have to break for every harmless change.

    Then it's just stepping and debugging and figuring out what went wrong.
    This is a typical approach for me and very successful, I might add.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  4. #4
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    Unfortunately MS debugger didn't find anything, so I looked through my code 3 days long till I found it was a very seldom hit'ed race condition inside a 3rd party library.

    At least I learned very much about my own code during that time

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Problems with shared memory shmdt() shmctl()
    By Jcarroll in forum C Programming
    Replies: 1
    Last Post: 03-17-2009, 11:48 PM
  2. To find the memory leaks without using any tools
    By asadullah in forum C Programming
    Replies: 2
    Last Post: 05-12-2008, 08:54 AM
  3. Memory usage and memory leaks
    By vsanandan in forum C Programming
    Replies: 1
    Last Post: 05-03-2008, 06:45 AM
  4. Memory handler
    By Dr. Bebop in forum C Programming
    Replies: 7
    Last Post: 09-15-2002, 05:14 PM
  5. Im so lost at . .
    By hermit in forum C Programming
    Replies: 18
    Last Post: 05-15-2002, 02:26 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21