Look at the memory location of 0x00b1eaa5 and look at the call stack to see if you can determine the cause of the corruption. If the array is within bounds, check prior calls for corruption.
Printable View
Look at the memory location of 0x00b1eaa5 and look at the call stack to see if you can determine the cause of the corruption. If the array is within bounds, check prior calls for corruption.
I used to work with BoundsChecker and in most cases it's no good.
Maybe you should try purify.
Anyway if the corruption always happen in the same memory address , you can place a breakpoint so the program will stop when this address is being written.
I didn't noticed if you say if you run in debug or release.
If release then cancel all you'r optimization.
If nothing work then just devide the program and check each section.
I've looked at the call stack and everything seems ok. I've tried putting a break point on the indicated memory location but it doesn't fire.
What I'm doing now is basically using the class that exhibits the problem as a 'yellow canary' (if it dies, it's time to get out of the mine shaft). If I place it earlier in the instantiation order it's problem goes away (replaced by issues with other classes later down the line). I am hoping that this means that the problem could be caused by one of the intervening classes in the instantiation order. I'll be looking at them carefully today.
Thankyou for all your ideas everyone. I'll greatfully accept any others thrown my way.