Re:My Bug, My Bad: Sunk by Float
by kevingadd on Tuesday March 19, 2013 @09:24AM
(#5400696)
I had a bug along these lines in a C# application that was pretty fun to troubleshoot, because it only occurred when the runtime gave a particular float extra precision (by letting it live in full-size x87 registers).
I was using an unmodified version of one of those standard 'triangulation by ear clipping' algorithms, transliterated directly into C#, using floats. In practice, it did exactly what I wanted and I wasn't using it much, so I never put much thought to it. Then it started going into an infinite loop in some cases. Troublesome.
So, I'd get it to go into an infinite loop, I'd attach the debugger, and... it'd leave the infinite loop. What?
Hm, identify the arguments that produce the infinite loop (good ol' printf debugging!) and reproduce those in an isolated test case. Great, test case enters an infinite loop, let's attach the debugger... hey, what? It's not failing anymore.
As it turns out, the default behavior for attaching a debugger to a .NET executable includes having the JIT deoptimize some of your method bodies in order to make breakpoints and local variables easier to work with (in their wisdom, MS did include an option to turn this off) - so any time I ran the test case under a debugger, it passed, because deoptimizing the method had caused the floating point math to flush to 32-bit float representation more often, truncating the additional precision. The infinite loop ended up being caused by that additional precision!
Best of all, the other platform I was writing the code for at the time (PowerPC) didn't exhibit the bug, because its floating-point implementation doesn't add additional precision.
I was using an unmodified version of one of those standard 'triangulation by ear clipping' algorithms, transliterated directly into C#, using floats. In practice, it did exactly what I wanted and I wasn't using it much, so I never put much thought to it. Then it started going into an infinite loop in some cases. Troublesome.
So, I'd get it to go into an infinite loop, I'd attach the debugger, and... it'd leave the infinite loop. What?
Hm, identify the arguments that produce the infinite loop (good ol' printf debugging!) and reproduce those in an isolated test case. Great, test case enters an infinite loop, let's attach the debugger... hey, what? It's not failing anymore.
As it turns out, the default behavior for attaching a debugger to a .NET executable includes having the JIT deoptimize some of your method bodies in order to make breakpoints and local variables easier to work with (in their wisdom, MS did include an option to turn this off) - so any time I ran the test case under a debugger, it passed, because deoptimizing the method had caused the floating point math to flush to 32-bit float representation more often, truncating the additional precision. The infinite loop ended up being caused by that additional precision!
Best of all, the other platform I was writing the code for at the time (PowerPC) didn't exhibit the bug, because its floating-point implementation doesn't add additional precision.