Thread: Memory Corruption

  1. #1
    Registered User
    Join Date
    Jun 2008
    Posts
    4

    Memory Corruption

    Hi everyone.

    I've memory corruptions that happens once in a while in random places of my code. One of those places looks like the one below...

    Code:
    Viewport *pViewport; // initialize pViewport IS ALWAYS a valid viewport
    pViewport->getTransformation( TRUE )->unMap(
    	&m_origin,
    	pViewport->getBounds()
    );
    The program crash in pViewport->getTransformation since pViewport is unresolved.
    The problem is I've stepped through the debugger a lot of times and make sure that the program execute in exactly the following order
    Code:
    1. // initialize pViewport
    2. pViewport->getBounds(){return this->m_bound; /* a valid rect structure*/ }
    3. pViewport->getTransformation(); // missing pViewport here... pViewport suddenly points to 0x000000c once in a while
    4. pTransformation->unMap();
    BUT when executing getBounds, pViewport is STILL valid, but when executing getTransformation(), pViewport disappeared causing access violation ending in crash.

    Is there anyway around this problem? Could it be caused by my bad coding habit rather than "memory corruption" which I presumed? The access violation happens once in a while (once after millions of loops maybe) and it always occur in different places (rarely hit the same place). However, it always happen in situation resembling the one above ( missing reference suddenly)

    Thanks a lot for the help!

  2. #2
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Does it work better if you don't chain three calls at once, but use temporary variables to hold the returned pointers?

    Getting a value of 0x0000000C is a fairly clear indication of uisng a null-pointer [+ a bit of offset], which is generally not a good thing to do.

    --
    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
    Registered User
    Join Date
    Jun 2008
    Posts
    4
    Thanks for the prompt reply, matsp!

    I would change my call mechanism, however, in other instances it did not happen in chained calls but on the subsequent calling statement. I decide to post the chaining sample to demonstrate that the pointer becomes invalid right after the statement where it was valid.

    And sometimes, it crash with the message "access violation reading location 0xXXXXX" or "instruction at memory location 0xXXXXX cannot be read" where XXXXX (values other than 0) reads as "expression cannot be evaluated" in the debugger. Does the two error message means the same? It sounds similar to me..

  4. #4
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    The problem with "chained calls" like that is that they are horribly hard to debug - because the intermediate results are not stored anywhere, so there is no way to look at them after the return of the function. I'm sure the compiler isn't getting it wrong, but YOU may not see a NULL-pointer somewhere in the sequence. [Not to mention that it is hard to debug chained calls even when each individual call goes right, and a good optimizing compiler will give the same or very similar resulting code for temporary variables as it does for chained calls almost every time - because the compiler can not produce the call-chain without some temporary storage of some sort or another anyways].

    As to your question regarding the two error messages: yes and no.

    The message saying "memory at address X can not be read" means that you are trying to read memory that has no virtual to physical mapping. A read in this case usually means that you are doing "p->x", where p is not a valid pointer (e.g. NULL or some rather random value).

    The message saying "instruction at address X can not be read" is essentially the same problem, but in this case, you are trying to EXECUTE (call a function) that is at an invalid memory address. "p->func()" where func is a virtual method would cause this to happen.

    --
    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.

  5. #5
    Registered User
    Join Date
    Jun 2008
    Posts
    4
    Wow., thanks very much matsp! Now that I know the difference, I will go back and check each specific logs.

    In simple-minded understanding, p->function() will generate "memory at address X can not be read" when p is invalid, but will generate "instruction at address X can not be read" where function() is a virtual method cannot be read.., but when will a virtual method cannot be read? the compiler will tell when the virtual method is not implemented.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 4
    Last Post: 01-13-2008, 02:14 AM
  2. Question regarding Memory Leak
    By clegs in forum C++ Programming
    Replies: 29
    Last Post: 12-07-2007, 01:57 AM
  3. Memory problem with Borland C 3.1
    By AZ1699 in forum C Programming
    Replies: 16
    Last Post: 11-16-2007, 11:22 AM
  4. Memory Corruption
    By cyreon in forum C Programming
    Replies: 3
    Last Post: 11-15-2007, 03:52 AM
  5. Shared Memory - shmget questions
    By hendler in forum C Programming
    Replies: 1
    Last Post: 11-29-2005, 02:15 AM