I wrote this document way back in 2010, which I found sitting on my computer. I wrote it for folks in our QA department. But I thought it good enough to share with other folks since it describes some basic things. So here is the document:
In a debug build of max, uninitialized memory is initialized with not garbage, but a certain pattern used to help catch bugs: 0xcccccccc.
Uninitialized memory is marked with this pattern to help catch bugs. For any pointer dereferencing this value will cause an access violation and crash the application.
The animation reaction manager displays a curve control. That curve control can of course display many curves. Each curve can contain many key points.
And here are the points:
The problem is manifested when you insert a point into the middle of the curve. You should expect this:
But instead, in a debug build you get this:
The problem is not the curve control, but actually the reactor controller. The reactor controller goes back and alters the points after the point was correctly inserted. (A bug was fixed by me btw) This reactor controller does its dirty business after the UI widget has already correctly displayed its data. This highlights two bugs:
1. Why is the reactor controller modifying the UI control when the UI was already correctly displayed?
2. Why is the reactor controller modifying the point with such a massive value?
The point where the first point gets altered is in the Reactor::UpdateCurves function in the following file:
In this code:
CurvePoint pt = curve->GetPoint(0,i);
The value for slaveStates[i].fstate is the following floating point number:
Where did this value come from?
Well examining it in the debugger’s memory shows this:
memory address of some memory:
As you can see, a debug build take uninitialized memory and fills it with 0xcccccccc. This is to help catch errors. Now if you take that value and interpret it as an integer you get:
And if you interpret it as unsigned integer you get:
And if you interpret those bits as a floating point number you get:
That is scientific notation for -1.0737418 x 10^8, or simply -1.0737418 x 100,000,000 or rather, -107374180.0. Or basically negative 107 million.
So this explains why the value of the first point is such a massive negative number. Solving this bug is not the point of this document, but is another story altogether.
In every single Debug build (On Windows platforms), all over the world, all uninitialized variables (on windows platforms) will always be 0xcccccccc. That number is always rendered as the same floating point value shown above. It is always the same with NO EXCEPTIONS.
That means if you want predictability in reproducing bugs you go with a debug build. If you want random behavior you go with a release build:
Here is the same work-flow in a release build:
Max 2010 (Release build):
The inserted point has a completely random y position (thankfully not as big as -107 million!). Also the first point is assigned to a random value. What is the random value? It is whatever the value was the last time memory was used there in that memory location. That memory could be clean, or it could be leftover from anything else. It could be memory that was last used 2 seconds ago, or 2 hours ago, or 2 days ago.
So again, if you see bugs with random behavior, it’s most likely an uninitialized variable. If you want to narrow down the repro steps, and actually solve it, use a debug build.