Beat this bug!

Member
Posts: 72
Joined: 2004.06
Post: #1
this works:

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!

"So long and thanks for all the fish" - In memory of Douglas Adams.
My Site
Quote this message in a reply
Nibbie
Posts: 1
Joined: 2010.11
Post: #2
I have found that you can sometimes kill these "bugs" by cleaning and recompiling...
Quote this message in a reply
Moderator
Posts: 522
Joined: 2002.04
Post: #3
What happens if you step through the problem in the debugger?

-Jon

p.s. I don't have any bugs. Rasp
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #4
Usually means you have a memory trasher elsewhere in your program.
Quote this message in a reply
Moderator
Posts: 522
Joined: 2002.04
Post: #5
I agree with the talking cookie. I was mostly wondering why you were printf'ing.

-Jon
Quote this message in a reply
Member
Posts: 72
Joined: 2004.06
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?

"So long and thanks for all the fish" - In memory of Douglas Adams.
My Site
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
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.
Quote this message in a reply
Oldtimer
Posts: 834
Joined: 2002.09
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.
Quote this message in a reply
Moderator
Posts: 370
Joined: 2006.08
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 Wink
-wyrmmage

Worlds at War (Current Project) - http://www.awkward-games.com/forum/
Quote this message in a reply
Post Reply