Smooth Moves

[adramolek]

So I had this bit of strange looking code:

if (led->m_to != prev &&
(FCanCrossSelf || !_hit[led->m_to->m_index]));
{
cango.push_back(i);
}

I was having a problem where it was getting into the if statement even
when the condition was supposed to be false. I could not, for the life
of me, figure out what was going on. The condition has so many braces
and arrows and things in it, and I had been staring at it for so long.
Why was it getting into the if statement when the condition was false?
I could print debugging info from inside the statement and verify it
was false. I could step through in my debugger and watch it step into
the statements, even when it evaluated to false. What was going on?

Well it's obvious when I look at it now, but after *over* an hour of
debugging, looking at conditions, looking at other code, checking for
buffer overruns in strange places, I *finally* spotted the damn extra
semicolon I accidentally typed at the end of the "if". See it? It's
right there before that left curly brace.

I slapped myself on the head pretty hard after realizing how dumb the
mistake was. It's not the first time I've spent a long time debugging
a simple syntax mistake like that.

So now, I am taking a break for a few minutes, and I am wondering:
what kinds of horror stories do people here have about silly mistakes
like this one? Hours spent debugging when you typed a j instead of an
i, or put a parenthesis in the wrong spot, an extra semicolon, a
problematic #define. There's got to be some good stories out there!

- AJ

 

[Jim Langston]

So I had this bit of strange looking code:

if (led->m_to != prev &&
(FCanCrossSelf || !_hit[led->m_to->m_index]));
{
cango.push_back(i);
}

I was having a problem where it was getting into the if statement even
when the condition was supposed to be false. I could not, for the life
of me, figure out what was going on. The condition has so many braces
and arrows and things in it, and I had been staring at it for so long.
Why was it getting into the if statement when the condition was false?
I could print debugging info from inside the statement and verify it
was false. I could step through in my debugger and watch it step into
the statements, even when it evaluated to false. What was going on?

Well it's obvious when I look at it now, but after *over* an hour of
debugging, looking at conditions, looking at other code, checking for
buffer overruns in strange places, I *finally* spotted the damn extra
semicolon I accidentally typed at the end of the "if". See it? It's
right there before that left curly brace.

I slapped myself on the head pretty hard after realizing how dumb the
mistake was. It's not the first time I've spent a long time debugging
a simple syntax mistake like that.

So now, I am taking a break for a few minutes, and I am wondering:
what kinds of horror stories do people here have about silly mistakes
like this one? Hours spent debugging when you typed a j instead of an
i, or put a parenthesis in the wrong spot, an extra semicolon, a
problematic #define. There's got to be some good stories out there!

I think we've all had these types of situations. I've ran into that exact
situation before, the extraneous semi colon.

The first time I ever ran into a debugging problem when when I decided to
write a simple game on an Apple ][e computer in Jr. High school. It was a
simple shooter with a submarine and aircraft shooting at each other with a
joystick, but the aircraft always fired first since it was checked first in
the code and so would always win. I wrote a line of code to fix the
problem, but then weird things started to happen. I looked over the code
over and over and couldn't find the problem. After an hour I decided to
look at it charcter by character and finally found a 1 instead of an I
(that's a one instead of an eye).

Another incident happened many years later, I was writing some code for a
company that was selling natical charts which had a 5 digit identifier.
This was on a PC with a 10 megabyte hard drive and correction files were
downloaded off of NOAA's database and stored to the hard drive under the
file name of the chart, such as 18720, 18740, 18746, 123, etc.. I didn't
write the code that downloaded the files (was written in Syphony) but they
had the problem of a directory listing being in the wrong order. Chart 123
should be before 11720 but the system was sorting alphanumerically. So I
wrote a simple Borland Pascal program to get a directory listing in memory
and using a swap sort sort the list. This was as far as I got then I tested
it and found that it was extremely slow, something like 10 minutes to finish
loading and sorting, no output yet. So I did some research and found a
buble sort somewhere and coded it in Pascal from the Basic source code.
After coding and compiling I tested it, the program ran and ended. Dang, I
checked the code to find out why it wasn't sorting but jsut ending. After
about an hour and a half of trying to find the error, which I couldn't find,
I decided to put in some output and try to step through what was going on.
After a few lines of output I found out that the problem wasn't with the
program, but with me. Bubble sort sorted the list in nothing flat. Sub
second sort for the list. I had spent a few hours trying to find a bug that
didn't exist.

That program taught me a few things, as when I designed it I asked them how
many charts they would have listings for so I could set the array
accordingly. They gave me some number, I asked htem if they were absolutely
positve it would never be larger than that, they abosultey said yes, so I
made the array 10x larger. They said that was too large, I said it was for
growth. Six months later they called me back, the program was crashing. I
checked and found that even with the 10x expansion of hteir estimate, their
list had grown too large. Worst though was the source code was no where to
be found. I would have to write it over again and I would have to find the
code for the buble sort again as I didn't understand it. But then I
remembered. I had started out with the directory listing which I had gotten
from some other magazine, and it had originally accepted a parameter for
file wilecard, I had left that in but defaulted to *.* if nothing was input.
With some creative batch programming I was able to grab all files starting
with '0' and do a sorted list, then '1', then '2' etc... so that the array
wasn't over flown in memory.

 

[Paavo Helde]

(e-mail address removed) wrote in 59g2000hsb.googlegroups.com:

So now, I am taking a break for a few minutes, and I am wondering:
what kinds of horror stories do people here have about silly mistakes

I think one of the best was when I accidentally entered íf instead of if.
After getting some spurious errors I spent a lot of time checking the
braces, the previous statements, semicolons etc. It never occured to me
to look at the if word itself. However, finally I noticed that the syntax
coloring had failed to color it...

And just today I copy-pasted a little function from one file to another,
and it stopped compiling, complaining that T is not a type name:

/// Cast from signed integer pointer to unsigned integer pointer or back
template<typename T, typename U>
T sign_cast(U p) {
// .. some checks
return reinterpret_cast<T>(p);
}

Fortunately I have the habit to (nervously?) move around in the text by
arrow keys when thinking, and I noticed that when going up or down in the
text the "template" line is jumped over. It appeared that copy-pasting
into text-mode emacs window somehow managed to screw up the linebreak
before the "template" line - probably replaced by CR, so that everything
looks OK on the screen, but the compiler thought template line was just a
continuation of the comment...

Regards
Paavo