Jump to content
  • Advertisement
Sign in to follow this  
Kest

Code demons again (real this time). Memory molestations.

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

My project has began randomly crashing at a certain function, on a specific line of code. The problem doesn't make any sense. I was assigning a const reference to an array node, then on the very next line, trying to use it - which is bringing up an access violation. The only insane possible thing that could have been happening was that memory was being molested outside of my code. But how could memory be modified outside of my code that effects the exact same two lines of code in my project every time I tested it? And I've got it to cause the violation about 10 times so far. The final time, I tried something crazy. Right under the assignment operation (setting the const reference to the array node), I checked to make sure it was still assigned. I checked to make sure six times in a row. Guess what? The 5th check failed on that test. Here's a snapshot. My _V() function just throws an error if the passed value is false. After the error occurs, the reference address is incorrect. But the original array node is still fine. Does anyone know what could cause this? I've never seen anything like it before. I'm also running a new divx encoding program in the background. That couldn't have any effect on the memory of my application, could it? I mean without throwing it's own access violation? Thanks for any help

Share this post


Link to post
Share on other sites
Advertisement
You're doing something wrong, not some other app. You're running in your own address space, and nothing else is touching it.
You're writing out of array bounds somewhere, or trying to write to released memory or an uninitalized pointer.

Share this post


Link to post
Share on other sites
Quote:
Original post by tok_junior
You're doing something wrong, not some other app. You're running in your own address space, and nothing else is touching it.
You're writing out of array bounds somewhere, or trying to write to released memory or an uninitalized pointer.

Then how is memory changing in between two lines of code that doesn't modify any memory?

The verification code is exactly equal to if( &ref != &array.node[e] ) Error();

How could calling this code six times cause memory to change on the fifth call?

Share this post


Link to post
Share on other sites
Just a uneducated guess, but it seems to me the problem is either in KCharAnim::GetEvents() or KCharAnim::GetEvents().Get(e)... Any reason why it wouldn't be??

Cheers
-Scott

Share this post


Link to post
Share on other sites
Set a memory breakpoint and determine when it fires.

This might be a symptom of using memory which used to be valid, but has since been deallocated (as would be the case when returning by reference a stack variable).

Share this post


Link to post
Share on other sites
Quote:
Original post by Kest
The only insane possible thing that could have been happening was that memory was being molested outside of my code.

Then maybe it's not an insane thing that happens. Maybe you just have a bug in your code.


Quote:
That couldn't have any effect on the memory of my application, could it? I mean without throwing it's own access violation?

No. It runs in its own memory space. There's no one but your own process to blame, I'm afraid.

Share this post


Link to post
Share on other sites
Quote:
Original post by popsoftheyear
Just a uneducated guess, but it seems to me the problem is either in KCharAnim::GetEvents() or KCharAnim::GetEvents().Get(e)... Any reason why it wouldn't be??

Because both are just inlined code returning variables.

Quote:
Original post by ToohrVyk
Set a memory breakpoint and determine when it fires.

This might be a symptom of using memory which used to be valid, but has since been deallocated (as would be the case when returning by reference a stack variable).

But as I mentioned, the original array node is still intact. Only the reference is incorrect. The reference that is set one line above the crash point. Is there a way to set a memory breakpoint on a reference variable that is declared one line above where it causes the problem? The function is called thousands of times before it randomly throws this memory access problem, and each time, the reference variable has a new address.

Share this post


Link to post
Share on other sites
Quote:
Original post by Spoonbender
Quote:
Original post by Kest
The only insane possible thing that could have been happening was that memory was being molested outside of my code.

Then maybe it's not an insane thing that happens. Maybe you just have a bug in your code.

I'm open to clues. What kind of bug would it be? I don't use more than one thread for any of my own routines. How could that memory change between two lines of code that is repeated 4 times before it?

Share this post


Link to post
Share on other sites
Quote:
Original post by Kest
I'm open to clues. What kind of bug would it be? I don't use more than one thread for any of my own routines. How could that memory change between two lines of code that is repeated 4 times before it?


It wasn't modified between those two lines. It was likely corrupted much earlier. Memory stomping bugs are evil for precisely this reason. Just because memory is corrupted doesn't mean the application will crash; it might run forever just fine and all you'll see is wierd un-reproducible bugs in your application; it might crash.

It's also perfectly fine to read bad memory, it's just not ok to write to it.

So couple things to look for:

1) any place in your app where you are iterating over an array, make sure you are properly checking for out of bounds
2) any place where you are using C-strings instead of std::string
3) any place where you are using a pointer that wasn't first initialized to NULL

-me

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!