Stupid Errors!

I once spend a couple of hours debugging my TGA loading code. It worked fine for large textures, but small texture had some weird offset bug. It turns out that I was reading half of the TGA header, the useful information and skipped the other half of the header, but I never set the file pointer to the end of the header. The result was that each pixel had A and R values from the previous pixel. When I finally fixed the bug I wanted to smack myself in the face!!! :-)

I spent about 90 minutes the other day tracking down a strange bug on application shutdown. Turned out I had forgotten a virtual destructor.

When writing my own (quirky) linked list functionality I couldn't figure out why my findnode function wasn't working.

Turns out I forgot a one line statement at the top of the function which causedit to skip the entire while loop.

I tried to solve it for a couple of hours before starting the debugger (if you've ever tried to use dev-cpp's debugger you'll know why). Needless to say, I quickly found the problem.

moral of the story: use gdb, but not through dev-cpp.

EDIT:
Yesterday I was trying to get SDL_ttf, opengl texture mapping, and unicode all working at the same time (advice: don't do that), but the texture kept turning up white. The problem: My new laptops opengl driver doesn't support non power of 2 textures. Of course that was the last thing I tested!

A few weeks ago, i spent an afternoon and the next morning chasing another stupid bug. So on the middle of the afternoon, i started to locate where exactly the bug was by adding some printfs with flushs' to the code. Well, on the end of the next morning i started to dispair because i've looked at the zone where i've pin-pointed the code about 100 times and it was all ok... i just couldnt get it. Then i just looked at the printfs and realized they were wrong (one of the variables i was printing was the wrong variable). I corrected that and after 5 minutes i knew exactly were the bug was... 10 mins later it was fixed [disturbed]

Beware of debugging when you are tired...

About 6 months ago my A* pathfinder kept on crashing. After 6 hours of hair pulling I realized that I needed a copy constructor for one of the classes that held pointers (thanks to gamedev!). Untill then I had never heard of them.

I was recently upgrading my little D3D sprite engine to use textures. I spent literally three hours trying to work out why the textures wouldn't display before I discovered I wasn't assigning a value to the rhw components of the verticies.

My personal favourite is still the time I spent trying to work out why a project was not linking correctly. I eventually discovered that I was missing a newline at the end of my makefile and it was ignoring the last line.

The ones that bug me the most is when you comment out a line or two so you can more easily test another module in your program (or to see if it was the problem) but forget to add the lines back in. Especially when the missing lines effects dont show up for a couple of hours, lost far too many hours on silly things like that.

At work, I worked a lot on data-conversion code (from proprietary formats to common ones and back, to make editing easier). At first, all was well, but eventually the users of the tools came back to me with "It works fine for small images, but the large ones get corrupted". I spent about a week going over my code (among other things, but lots of debugging), making sure there weren't any sign issues and that I was outputting the header correctly, etc. Eventually it turned out that Photoshop CS2 doesn't load BMP files correctly - it treats the size fields as 2-byte numbers when they're actually 4-byte numbers. I had to competely rewrite the tools to convert back and forth to TIF images, because apparently it handles them correctly (and a bit of work using the tools had to be redone since the bug wasn't noticed initially).

It helps to check the other programs you're using, even if they're insanely expensive commercial programs with a large reputation.

Then there is the part that actually is my fault - in a class designed to read in the proprietary formats, the functions basically operate by calculating the appropriate offset, seeking to it, then reading it into a buffer. For some reason, I used a signed number for the offset instead of type defined by the stream class, and that caused a headache too when files larger than 2GB just wouldn't load. Luckily, files larger than 4GB aren't needed, because it'd be a real pain to have to use windows file functions directly (or to read the MSVC iostream code to make sure it uses 64-bit numbers).

The funniest thing that sticks out to me is back in university someone was having a trouble for the entire of a 2 hour workshop getting his program work.

I saw the problem after a minute looking through the code. It looked something like this

if (xyz==0);
return someResult;

... oh those semi-colons at the end of if statements [wink]

A couple weeks ago I was working on a windows service and couldn't get the damn thing working for anything. I spent hours and hours trying to track down why it wouldn't start and finally I remembered I could run it as a console app as well. I finally got a useful error message!

Quote:

This application has failed to start because applib.dll was not found.

delete myActor;// Somewhere elseif(myActor != NULL) {	frob(myActor); // F---}

[crying]

During the time when I still used makefiles to build my projects (I use jam now. Much better IMHO ), I could run into weird errors when I had started writing on a new source file and maybe modified one of my old header files to be more compatible with the new "module" I was writing. Because I was to lazy to tell make about what header files were needed by what source files [rolleyes], so old object files would stick around that used my un-modified header files' declarations. I sometimes felt like I was going crazy when code I thought I didn't even touch started to fail and I would sit there debugging for hours before finally realizing that maybe I should rebuild the whole project and suddenly all errors go away[totally]

delete this; doesn't work with virtual inheritance. As I found out after about 6 hours of debugging with CodeWarrior's crappy excuse for a debugger.

Quote:

Original post by Evil Steve delete this; doesn't work with virtual inheritance. As I found out after about 6 hours of debugging with CodeWarrior's crappy excuse for a debugger.

Mm, that one used to stick me for years until I bothered to actually read up why it does that. Have you read the Writing Great Code series? Vol. 2 has a lot of insights on polymorphism that just struck me dumbfounded.

Quote:

Original post by Ravuya Quote: Original post by Evil Steve delete this; doesn't work with virtual inheritance. As I found out after about 6 hours of debugging with CodeWarrior's crappy excuse for a debugger. Mm, that one used to stick me for years until I bothered to actually read up why it does that. Have you read the Writing Great Code series? Vol. 2 has a lot of insights on polymorphism that just struck me dumbfounded.

Nope, but I asked about it around here, and it makes sense now I think about it. The problem was that it worked fine with the default operator new, just not my overloaded one. I still blame CodeWarrior. I don't care if it's not it's fault, it's still a sh*t IDE / compiler.