Bug stories!

This is a thread where we tell our stories of bugs that we fixed or couldn't fix.

I'll start:
I'm making an OpenGL program in sepples and I was trying to glGetString(GL_VERSION) so I can see if everything is working on Windows.

Every time I even made a function call? My program would crash. I couldn't for the love of my life find this god damn bug and started shouting and planning to plant pipebombs at Microsoft.^[1]

Turns out I made a global object which when instantiated would call that function from it's constructor. It seemed reasonably appropriate to place that function call there for the moment since I'd remove it later.

When you don't have an OpenGL context? Any OpenGL function calls you make result in undefined behavior; read: program crash.

Your turn.

_{[1] Not actually. Although I should make a 'pipebomb microsoft to hell' doom clone.}

As someone who works with ENTERPRISE Java, I've actually seen this construction more than once, written once in-house and once in a third-party library, as the root cause of the symptom ``Gee, why is our program dying on startup but not writing out any logs?''

public class SomeFuckingThing {

...

public static void setUpShit() {
try {
theGlobalErrorLogger = new GlobalErrorLogger("/hardcoded/path/to/configuration/file.xml");
} catch (IHandlePropertiesFilesLikeAMoronError ex1) {
dieWithNicelyFormattedError("Could not instantiate error logging", ex1);
}
}

...

public static void dieWithNicelyFormattedError(String text, Throwable cause) {
theGlobalErrorLogger.logFatalError(text, cause);
System.exit(0);
}

...

}

Why is everything in Java fucking static? The fuck is up with that?

I wonder if Java CAN be used correctly and in a way that doesn't result in a mess...

The only real frustrating bugs I've had were when using complex dynamic memory allocation structures in C that did lots of writes, and accidentally writing one byte past the end which wouldn't crash anything, but it would mess up the memory chunk information encoded right after the allocated block and cause free to fail / segfault at some random time in the program (with shitty glibc always telling me it was a double free).

Only occasion that stands out because it's hard to figure out what's actually causing it.

I once found a horrible timing bug where reducing the processing time in an ISR by a single cycle would cause another thread that was racing with the ISR to hang.

>>2
That kind of thing is obviously unacceptable in a library, but in all fairness how do you expect a program to deal with that? I'd probably use System.err in that situation but if the program is daemonized you'd never see that message, either.

>>5
The solution that we employed in both cases was ``Build the fucking logger so that it doesn't completely rely on a magic configuration file''. The damn things were overcomplicated already as it was, so if the configuration file is missing, we just redirect everything to a default foo.log in pwd and to stderr. If we can't open the file in pwd, we just give up and only print to stderr with a warning along the lines of ``Couldn't find a configuration file and can't write to pwd. This system is fucked up.''

At least we no longer have code in our error handling routines that explicitly causes a NPE (or, in one case, a NoClassDefFoundError because the whole thing was actually in a static{} block anyway).

_{Of course, the real problem is that we have two goddamn ``Global'' Loggers in one application, both of which rely on entire configuration frameworks that serve no fucking purpose besides handling two variables: 1) path to log directory, 2) how to rename log files when rotating. I kid you not: we have five configuration files to handle a grand total of 3 variables, because the path is shared. We intended to have them rotate the logs the same way, too, but even that got screwed up. One backs up to .log.X+1, one continues at .log.X+1}

>>3

Why is everything in Java fucking static?

"public static" is the Java's way to say defun or define, because Java has no standalone functions, like normal languages have. In other words, it a bad language design.

An image analysis library written by another in-company team destructively modified its input for no reason, and nobody knew about it because the author had left for Gensokyo. It never showed up in testing because a new dataset was constructed for each test, but under certain conditions you couldn't analyze the same objects twice. The first call would succeed, the second would get its indices confused and read in garbage.

When I raised the issue to the library team, they replied with approximately ``Line 1192 has no actual impact on the algorithm, so we've removed it. Our tests still pass 100%.''. Bug: fixed, mysterious issues we'd been blaming on test data for months: gone.

What we learned was ``If the language doesn't allow you to declare parameters immutable, make damn sure they're not mutated''.

>>8
Just use Haskell.

>>9
Haskell a shit.

>>10
Shit a haskell.