GF_*, MAX_GF, And You

[chris]

I love debugging. I love it even more when after an hour or so, I realize that I made a stupid, stupid mistake.

Like, suddenly I can't open my save files, and max_k_idx is set to 17. Hmmm ... that can't be right? The savefile value of 672 sounds more like it. Lemme recompile the world.

Now, I still can't open save files, but this time it is max_wild_x that is set to 17. The savefile value looks fine, so something is stomping 17's at random memory addresses!

Eventually, I tracked it down to developer stupidity. I added a bunch of new attack types GF_This and GF_That, but stupidly forgot to bump up the MAX_GF sitting right below my code. Somewhere there was an array initialized to be MAX_GF elements ...

Duh! I feel so dumb :P

Sorry, I just wanted to share my pain ... What has been your worst debugging experience? And when all was said and done, was it your fault?

[Sirridan]

I did the same thing when I tried to add some new mushrooms to V a while back (successful btw). I tried to make a cast effect on one after you eat it, and I forgot to add an entry to some table and I kept getting bad pointers and ugh it was a mess. Totally my fault.

My favorites are always the missing counter resets in while loops, or misplaced semi-colons, two hours of debugging to find such a thing *facepalm*

[Nick]

The good news is that we all do it.

The bad news is that you'll do it again.

[Magnate]

The good news is that we all do it.

The bad news is that you'll do it again.

And none of it will ever, ever surpass the time you spend tracking down and fixing off-by-one errors. I've only been coding for about two years and already I'm stunned by the far-reaching effects of off-by-one errors: crashes, infinite loops, data corruption, the works. It's now the first thing I think about when anything isn't quite right.

[PowerDiver]

And none of it will ever, ever surpass the time you spend tracking down and fixing off-by-one errors. I've only been coding for about two years and already I'm stunned by the far-reaching effects of off-by-one errors: crashes, infinite loops, data corruption, the works. It's now the first thing I think about when anything isn't quite right.

The first serious debugging lesson I had was for a final project, using Pascal I think, where a compiler bug caused a for i = 1 to M loop to execute twice when M was 1. That was my ultimate off-by-1 error.

My most common reason for head thumping over the years has been correct code with incorrect debugging output.

[d_m]

And none of it will ever, ever surpass the time you spend tracking down and fixing off-by-one errors. I've only been coding for about two years and already I'm stunned by the far-reaching effects of off-by-one errors: crashes, infinite loops, data corruption, the works. It's now the first thing I think about when anything isn't quite right.

Honestly, I think memory management errors trump off-by-one errors, if only because the program will often behave correctly while actually being incorrect. Those are the errors which are super hard to replicate, let alone isolate.

[Derakon]

This is why many scripting languages support iterating over objects in lists instead of over list indices (eliminating most common sources of off-by-one errors) and handle their own memory management.

My best boondoggle of a debugging story boils down to "Hi, welcome to $newjob. Here's a program written by $previousEmployee. It's 20k lines of Python and 5k lines of C++, and he learned to code as he went along. It crashes sometimes. Please fix it." But that's not really fair, because it wasn't my fault it was broken in the first place (and to be fair, given the author's experience level and the complexity of the tasks the program had to perform, it's impressive it worked as well as it did!).

[kaypy]

My favorite in terms of war-storyness is the time I spent the better part of a day tracking down a problem where the new code I was writing just didn't seem to do anything. Eventually I got to the point of adding a print statement right at the start[1], which proved it genuinely wasn't doing anything- because it wasn't being called. After much head scratching and more "whats really being called?" print statements, I finally found that the method I was writing differed from the one it was supposed to override by one character being upper case...

[1] This sort of test has been *much* higher in my toolkit priority ever since...

[chris]

It's 20k lines of Python and 5k lines of C++, and he learned to code as he went along. It crashes sometimes. Please fix it."

About the "It crashes sometimes," at least we don't have to deal with threading issues on Angband Those can be really difficult to track down since they are often timing dependent. As luck would have it, sometimes a user's machine is "just slow enough" to reproduce the unreproducible every time ... sigh.

But yeah, I come from a C++ background where collections were safe, offered brain dead enumeration options (like for_each) and memory allocation was safely protected (auto_ptr). However, I still often get boolean conditions exactly backwards sometimes ... not sure why?

[Timo Pietilä]

However, I still often get boolean conditions exactly backwards sometimes ... not sure why?

Everybody does that sometimes. I have this problem with sql sometimes because of my work. Something that belongs to this but not this and is not this but has to have something that is like that mixed with joins and parenthesis that include several of them together etc.

When you stare about ten lines long sql-query that looks like that you get boolean out of your ears. Usually error is parenthesis in wrong place or missing/extra "not" somewhere.