Quote:Original post by Moomin
Does the function being called alter any memory?

It's stack-based memory that is being changed. So if I'm not mistaken, everything that executes is altering it. Even parameter values being sent to functions is altering stack memory. Right?

But to answe the question, no. No functions are modifying any memory other than stack memory after Anim_FindFirstEventHaltPoint() is called and before the access violation.

And all of these related functions have been in place for many months. I only first encountered the problem a few hours ago.

Quote:Original post by Palidine
It wasn't modified between those two lines.

Yes, it was. The value of the stack variable reference actually literally changes in between those two lines of code. Whether it is changing because of a bug that happens earlier is unknown to me. But that reference is the only thing that's clearly wrong.

The problem is still occuring after a complete rebuild. Here's another test. Check out the watch-window values of the pointers. Both are different, and both are incorrect:

can you show the code for the Get method? Is it popping off a stack or something?

Also, any chance you are running in release instead of debug?

-me

Are you sure GetCount() in your for loop is returning the proper value?

Quote:Original post by Palidine
can you show the code for the Get method? Is it popping off a stack or something?

Also, any chance you are running in release instead of debug?

The function belongs to a templated class. < type > is the only template variable:

const type& Get(int index) const{ return *Refs[index]; }

I'm in debug. The access violation actually first occured when I ran it outside of the debugging environment.

Quote:Original post by _Sigma
Are you sure GetCount() in your for loop is returning the proper value?

The value of e is 1 in the first snap shot. The array size is 2. Also, array[1] is a valid index and has the correct values. Only the reference is wrong. Even if I was trying to reference outside of the arrays bounds, the address value of array[1] and the reference variable address should still match.

So it sounds like another application can't change memory in the stack that effects my program. My code also uses only one thread to execute. What about other threads that run with my program? Such as the timer, directx, or etc? Is it possible that some part of my code is ripping on them - such as changing the address of one of their pointer variables - causing them to modify it and change something of mine? Or is that also impossible? Is there similar protection between threads that exists between programs?

Quote:

const type& Get(int index) const{ return *Refs[index]; }

What is Refs?

Who allocates it, what does its subscript operator do, are the elements dynamically allocated, ....

Quote:Original post by DrEvil
post GetEvents

Ahhhh crap..

Damn!

*Hangs head in shame*

GetEvents() was supposed to return a const reference to the array object. Instead, missing the & operator on the return value, it was returning a copy of it.

I can't believe this code has been running for months like this.

Thank you DrEvil, I am royally indebted to you. If there's anything I can do to return the favor, let me know. You probably just saved me a week.

Is there any way to avoid these types of typos? I could have more right now. Shouldn't the compiler warn about storing a copy of something being returned from a function into a reference variable?

Thanks again for your simple and insanely useful reply.

edit:

There's still one thing I don't understand, though. If there was a new copy being generated every time I called GetEvents(), then how did the first five validation checks succeed? Did it just happen to copy the array object over onto the same memory the first five times?

edit 2:

Uhh, I should also give thanks to popsoftheyear. If I would have looked more closely after his suggestion, I would have found it.

[Edited by - Kest on August 13, 2007 5:59:49 PM]

Quote:Original post by Kest
Is there any way to avoid these types of typos? I could have more right now. Shouldn't the compiler warn about storing a copy of something being returned from a function into a reference variable?

Nope. It's perfectly valid code. If something is already being returned by value (i.e. a copy) then you might want a reference to it if you're just doing local stack work. Otherwise, you'd incur 2 copies when you just need one.

-me