[angarg12]

I got a tiny one of these.

One time I was writing some code in C. I found a bug, the solution seemed pretty obvious, so I fixed it, recompiled the code, and ran it again. The bug was still there.

I took a look at the rest of the code in case that I missed something. I couldn't find anything, so I added a few print statements and recompiled. I ran the code and nothing came up.

Interesting, apparently the code is not executing the branches it should. I verified the input data and code. It didn't make sense, there had to be some serious bug there that I didn't consider. I added a bunch more prints.

Recompile and execute. Still nothing. Wait a minute, THAT doesn't look good. I added a print statement right at the entry point of the program. Nothing.

At this point the root problem became apparent; my changes just weren't getting compiled. Phew, problem solved! I cleaned all the cached files and recompiled the source code. Those print statements still weren't coming up.

At the end I had to move my source code to another machine and compile it there to get it working. I suspect some global variables or path trickery to be involved, but up to this day I still haven't got a clue what was wrong, or have I seen it happen again.

[zlynx]

Ahhahahaha. I have a similar story to that, but I eventually realized what happened.

I forget which command it was exactly, but I rsync'd or something to get a new code directory, and with the backup options in use the directory I was in got renamed.

But I still had command prompts open in that directory. And all of the files were there. So I didn't realize that one directory was not equal to the others even though it had the same name (it was a subdirectory) and appeared to have the same files.

[schemescape]

One similar story: I was maintaining some C++ code that had a few #ifdefs in it. Someone reported a problem.

I put a breakpoint on the calling code and traced into my code. It went into the #ifdef code I expected, but the problem persisted.

Just to double-check, I let the program run until it hit the breakpoint again and traced in, but this time, it went into the #else code! That code should have been removed by the preprocessor, yet here I was, currenting stepping through it.

After questioning my understanding of the C preprocessor (and my own sanity), I luckily noticed that the module name in the debugger was very slightly different in the two cases mentioned above.

The world finally made sense again. My code was in a header file that was compiled (with different symbols defined) into two different modules and both of those modules were loaded into the same process. When I set the breakpoint in the debugger, it silently set breakpoints in both modules.

[smallstepforman]

.o file stamp newer than .c timestamp. Make figures out file can be skipped. Run recursive touch on these problematic files and headers.

[yxhuvud]

The most fun is when the build then restarts, and do a build cycle until the the clock passes some magical timestamp making the build succeed.

[russfink]

More magical, your object files reside on a network shared drive that has a clock slightly different than that of the compiler machine.