Beat this bug!
Post: #1
this works:
the first time it's called, this doesn't work:
It just doesn't call QuaternionFromAxisAngle() as far as I can tell, not unless I've printfed it's address first :-D.
Eventually I thought of turning off zero linking. It worked fine after that. Well, everyone always told me zero linking was crap!
Post any "better" bugs here!
Code:
Vector QuadReflect(Quad* q, Vector* l)
{
printf("qr: %x\n", QuaternionFromAxisAngle);
Quaternion tq = QuaternionFromAxisAngle(q->normal, M_PI);
return VectorMultiplyByScalar(VectorRotate(l, &tq), -1.0);
}the first time it's called, this doesn't work:
Code:
Vector QuadReflect(Quad* q, Vector* l)
{
Quaternion tq = QuaternionFromAxisAngle(q->normal, M_PI);
return VectorMultiplyByScalar(VectorRotate(l, &tq), -1.0);
}It just doesn't call QuaternionFromAxisAngle() as far as I can tell, not unless I've printfed it's address first :-D.
Eventually I thought of turning off zero linking. It worked fine after that. Well, everyone always told me zero linking was crap!
Post any "better" bugs here!
Post: #3
What happens if you step through the problem in the debugger?
-Jon
p.s. I don't have any bugs.
-Jon
p.s. I don't have any bugs.
Post: #6
I printf'ed because I was trying to track down the problem and the debugger wouldn't step in to the function, it just stepped over. Also, how could I have a trashed memory bug that goes away by printfing the function address?
Also, why would a trashed memory bug disappear after the first call of the function?
Also, why would a trashed memory bug disappear after the first call of the function?
Post: #7
if the debugger won't step in, it might be because your program is optimized (use -O0 -g), because the debugger is lying, or because your program is really not going there...
Adding a printf changes the size of the code, which can change the part of memory that's getting overwritten to something harmless, or something that shows up at a different time. Whatever the reason, "adding a printf makes my program work" is a pretty common complaint.
If it's a stack trasher rather than a heap trasher, then the precise call sequence and arguments could be relevant. In that case, if you survive the first call, it might be that you never re-encounter the problem.
Unfortunately, if it's a stack trasher rather than a heap trasher, it'll be next to impossible to debug. Using mudflap or valgrind on Linux might prove more useful than the Mac OS X debugging tools.
Adding a printf changes the size of the code, which can change the part of memory that's getting overwritten to something harmless, or something that shows up at a different time. Whatever the reason, "adding a printf makes my program work" is a pretty common complaint.
If it's a stack trasher rather than a heap trasher, then the precise call sequence and arguments could be relevant. In that case, if you survive the first call, it might be that you never re-encounter the problem.
Unfortunately, if it's a stack trasher rather than a heap trasher, it'll be next to impossible to debug. Using mudflap or valgrind on Linux might prove more useful than the Mac OS X debugging tools.
Post: #8
It should be pointed out, however, that turning on Guard Malloc from the Debug menu, hitting Cmd-Y and then taking a 10-minute walk while your program starts pinpoints most heap smashers.
Post: #9
I've also found that going in and trying to optimize your code tends to help you find the source of the memory problem, because you have to examine your code extremely carefully while optimizing 
-wyrmmage
-wyrmmage
Worlds at War (Current Project) - http://www.awkward-games.com/forum/
