When you see a Heisenbug in C, change your compiler's optimization level (2010)

http://esr.ibiblio.org/?p=1705#

by adamnemecek • 12 years ago

52 82 12 years ago

esr.ibiblio.org

CJefferson• 12 years ago

“OK, set your optimizer to -O0,”, I told Jay, “and test. If it fails to segfault, you have an optimizer bug. Walk the optimization level upwards until the bug reproduces, then back off one.”

That is 99.9% rubbish. By which I mean in 99.9% of cases, when code works at -O0 and not at higher optimization levels your code has a bug, almost certainly involving invoking undefined behaviour.

Certainly it is possible to find optimiser bugs, I have done it myself, but it is many times more common for your code to have bugs. Now, you could argue that optimizers shouldn't make such extensive use of undefined behaviour, which leads to these kinds of bugs, but it is perfectly valid for a C compiler to do so.

cpncrunch2• 12 years ago

Agreed. Many times I've seen a bug disappear when I've added printfs or turned on -g, but I've never, ever seen an optimization bug in a C/C++ compiler.

The only time I've seen optimization bugs is in the emscripten compiler, but I'm sure those will be ironed out eventually (and the current version seems pretty stable).

infogulch• 12 years ago

That has happened to me as well. There's a bug until I add a printf or enable debugging, or (paradoxically) go from -O0 to -O2. What's going on here? Is there some specific class of UB that I'm invoking to get this infuriating bug?

userbinator3• 12 years ago

In nearly 2 decades I have seen only one compiler bug, in MSVC6, which was related to large switch statements.

The most successful way of finding what's causing these "heisenbugs" is to NOT change the binary, but just load it in the debugger as-is, make a guess at where it's failing, and set a few breakpoints/watchpoints. Either the compiler is not generating the code that you expect, or your expectations of the language were wrong, and both cases are fairly clear from looking at the generated code.

username223• 12 years ago

At some point many hundreds of years ago, the law became too complicated for people to navigate on their own, so lawyers (and Law French) were created. How long will it be before there are paid language lawyers, arguing for compilers vs. programs in an ANSI/ISO "court"? There's probably money to be made in "optimizer trolling," come to think of it.

ohazi3• 12 years ago

This is a little misleading.

Yes, when you see something like this, changing the optimization level may indeed influence whether or not the bug is visible, and is a useful tool for figuring out what went wrong. But these days it's pretty rare that the optimizer is at fault. Usually what you'll find is that the optimizer is indeed making a valid optimization, but your code is relying on unspecified C or C++ behavior that just happens to work when you're at -O0.

Your code is still the thing that's technically incorrect.

derefr• 12 years ago

Indeed, if you re-interpret the article's usage of the phrase "optimizer bug", then the advice becomes useful: if changing the optimization level fixes your broken code, you have an undefined-behavior bug.

Eiwatah4• 12 years ago

Either that, or a race condition.

johnbender2• 12 years ago

Isn't it often the case that the optimizations throw out sequential consistency guarantees?

That would introduce non-determinism in concurrent executions that might have nothing to do with the semantics of the program.

For example, I'm under the impression that the most recent C++ standard basically says "if you have no data races then all will be well" even though they may be benign data races like dual assignments of the same value.

Dylan168073• 12 years ago

C doesn't have any sequential consistency. Even without any compiler optimizations, the hardware will reorder things across cores. Subtly on x86, massively on Alpha. You can't use multiprocessing without some kind of external guarantees.

evanphx• 12 years ago

Ordering is basically an unspecified behavior in C. An optimizers best friend is the ability to reorder, perform CSE, etc.

C and C++ are specified as the behavior of a straight-line sequence of code run in isolation. Basically, any concurrent C/C++ program treads into the unspecified behavior area. Thusly it's not the optimizers fault, but C/C++ certainly aren't helping out at all.

Even the mechanisms that are common place to make a concurrent C/C++ program run correctly basically wade into unspecified behavior, for instance using asm("lock esp"), asm("mfence"), etc.

TL;DR: concurrency is unspecified in C.

ohazi3• 12 years ago

TL;DR: concurrency is unspecified in C.

One of the many reasons I'm eagerly the 1.0 release of Rust.

frozenport• 12 years ago

TL;DR: concurrency is unspecified in C.

Does the same argument apply to binary code ran on a preemptive operating systems? The actual execution order of your code is still unspecified, as the OS an interrupt it whenever it wants.

detrino2• 12 years ago

C11/C++11 define a memory model and provide assorted primitives.

wmil• 12 years ago

Technically yes, but the C++ spec gives the optimizer a lot of leeway, in ways that aren't necessarily safe.

Few programmers have a deep enough understanding of the C++ spec to realize things like how the optimizer is free to ignore NULL checks after a memory location has been accessed. They just see a `pointer == NULL` passing, then code failing on a null pointer.

And the problem is that they shouldn't need that level of understanding to write C++. The optimizer should be doing things like warning about unnecessary null checks that could degrade performance, it would notify the developer that there's a problem.

But that would cause issues for people working with large amounts of legacy code, so it's not done.

theseoafs7• 12 years ago

"Ignoring NULL checks after a memory location has been accessed" -- what do you mean by that?

aidenn0• 12 years ago

In the embedded industry, the most common reason for things working when disabling optimizations is violating the ANSI aliasing rules. Embedded programmers type-pun all the time and don't realize it's undefined behavior in C. Most compilers have an option to disable the ANSI aliasing rules, but it really hurts optimization opportunities.

I saw a large codebase completely break when turning on intermodule inlining. The cause: more opportunities for the compiler to find pointers that aren't allowed to alias.

cnvogel2• 12 years ago

Yes, and most often it's clearly warned about, up to the point where lines are completely burried in type-casts, just to shut up the (well meaning) compiler. Because, you know, we thrive for 0-warning compilations!

theseoafs7• 12 years ago

This is absolutely correct, and the article worries me for that reason. C programmers shouldn't learn "Heisenbug == compiler error" -- that's rarely the case. Compilers aren't generally formally verified, but they're also very heavily tested, and it will rarely happen that you expose a compiler bug. It's far more likely you're relying on UB in some way.

hajile• 12 years ago

The author states that this has only happened 3-4 times in 30 years. I don't see anything that would make a reasonable programmer suspect that this is always the case or even usually the case.

dave1010uk• 12 years ago

In this case it might be useful if compilers (or a test compiling tool) had a "go crazy for undefined behaviour option". This might be difficult to implement but could do things like randomise sort order where it's undefined. Similar to how fuzz testing an application's input, this would fuzz test the compilation phase.

greenyoda• 12 years ago

I've had a long career of writing C code that runs on many different operating systems and CPU architectures, and I don't think I've ever personally stumbled across a problem that was caused by a compiler bug. In my experience, heisenbugs (bugs that seem to disappear when you try to debug them)[1] are usually caused by bad memory references that corrupt different areas of memory - sometimes fatally, sometimes without visible effect - when the program is compiled in debug vs. release mode. For example, optimized code might put more variables in registers, thus changing the set of variables that are vulnerable to being clobbered by a buffer overflow.

Rushing to blame a bug in the compiler is, much more often than not, a way to waste a lot of time while debugging. Most commonly, we are the cause of our own bugs.

[1] https://en.wikipedia.org/wiki/Heisenbug

ja27• 12 years ago

It's been a few years since I've really had one, but corrupting or using up the stack space was the cause of a couple of cases of seemingly weird behavior in C.

dalke2• 12 years ago

While I'm fuzzy on the details now, one problem we had, back in the 1990s, was in C++ code which used comments with "\"s to make it look pretty.

   /// I am a comment! \\\
   a = 5;

The SGI OCC compiler accepted it just fine, as did most of the other compilers. I wasn't until we compiled on HP, or perhaps AIX, that we had a compiler which elided the "\" + newline to give

   /// I am a comment! \\a = 5;

and caused the downstream code to fail.

As for heisenbugs specifically, I agree with you. I just wanted to tell a story. :)

cnvogel2• 12 years ago

I had a similar story I'd like to share. A colleague had written out the initialization data for some embedded component, and helpfully included the ASCII representation for some of the (mixed) binary/readable stuff we sent. So he wrote something along the lines of...

            unsigned char initdata[] = {
               0x01,  // some value, e.g. 513
               0x02,  // as 16bit, little endian
               0x40,  // ASCII @
               0x5c,  // ASCII \
               0x42,  // ASCII *
               0x09,  // number 9
              (...)
            };

mansr3• 12 years ago

C99 explicitly does \-splicing of lines before comment processing:

  //\
  this is a comment

  /\
  / this is also a comment

GCC has an option (-Wcomment, enabled by -Wall) to warn about this and other likely mistakes involving comments (e.g. nested /* */ comments).

cjensen• 12 years ago

No no no no! I've had dozens of heisenbugs in my career. I've only seen compiler bugs once or twice.

spc476• 12 years ago

And the punchline: the heisenbug in question was in the code being compiled, not the compiler (http://esr.ibiblio.org/?p=1705&cpage=1#comment-248245).

jessaustin• 12 years ago

Indeed, one wonders whether that revelation might have been the entire reason for this belated post to HN. I don't particularly feel sorry for him, but ESR does get a hard time around here.

to3m5• 12 years ago

I think if the code changes due to adding or removing -g, that's definitely a bug in the compiler!

If the generated code does things that can't be represented in the debug info, there are plenty of better solutions, with generating useless debug info being an obvious one. Useless debug info is annoying, but far from the end of the world, not least because just about any experienced programmer will be used to it by now...

GFK_of_xmaspast2• 12 years ago

The only "compiler bugs" I have ever seen in 20+ years of coding have all, with the exception of the times the compiler itself crashed, all been user error, and most of those errors are things like using uninitialized values (-g, at least on some compilers, sets memory to 0, instead of 'whatever's on the stack at the moment') or stack corruption that corrupted different parts of the stack at different optimization levels.

mannykannot• 12 years ago

In the article's comments, the author of the code in question says "I 'solved' the problem by sticking in one trace call that made the problem go away. That kind of fix makes me vaguely nauseous, but ugly working code beats pretty broken code every time." He does not appear to have an explanation of the error that the optimizer is allegedly making, or for how this change fixes it.

If you have made a 'fix' but you don't know what problem it solves and how it does so, you probably haven't fixed anything, and you can expect further trouble from the root cause.

stusmall2• 12 years ago

I remember an almost impossible to diagnose heisenbug I had on an embedded device years ago. It was a small embedded system with no MMU and very poor tooling. It took 3 of us stuck in a room working long hours together for 2 weeks to trace it down. I ended up having to port portions of the code base to an easier to use system and luckily the bug ended up being in that subset of the code. The real kicker on this bug is we could never reproduce it with optimizations turned off so it was a constant battle between adding in diagnostics and trying to keep the bad behavior intact. Every little change we would make would shift were the memory corruption was and the reordering from the optimizations made the changes unpredictable at times. Ahhh, shitty memories.

I can't express the joy when the source of the bug ended up not being my fault.

That bug chase in particular made me extremely weary of people who alter systems to fix bugs without understanding exactly why it made the issue go away. It might not have fixed it but just moved it.

detrino2• 12 years ago

So what caused the bug ?

malkia• 12 years ago

This is what helps me finding bugs, and debugging release code (MSVC specific) - put this around function to disable temporary the optimizations:

  #pragma optimize(push)
  #pragma optimize("",off)

  void the_function()
  {
  }

  #pragma optimize(pop)

Usually some kind of bisection, or lucky guess is done to figure out that it's really compiler bug.

cwzwarich• 12 years ago

In my experience (which comes from developing compilers and bringing up operating systems on new architectures with untested compilers), compiler bugs are rarely 'heisenbugs' in the traditional sense, meaning bugs that go away when you attempt to debug them.

Compiler bugs tend to be more deterministic, where some code is being generated incorrectly and it will do the wrong thing every time you execute that code. Changing the optimization settings may cause the bug to go away, but it's still deterministic given the same compiled binary. One exception would be a bug where a compiler is reordering instructions across a memory barrier, but those are even rarer than normal compiler bugs, since compilers are generally paranoid about reordering anything with barrier intrinsics or inline assembly.

noselasd• 12 years ago

My version of this would be "When you see a Heisenbug in C, run your program through valgrind".

Which is a good idea even if you don't observe any bugs.

svec2• 12 years ago

Amen to that!

svec2• 12 years ago

When you see a Heisenbug in C, change your mind: it's NOT the compiler. It's you.

At least that's been my experience in almost 20 years of programming a lot of C and C++.

I've found my share of compiler bugs, particularly in embedded compilers, but 99%+ of the time the Heisenbugs are mine: stray pointers, stack overflows, buggy concurrency, unexpected interrupt timing, etc.

When you see a Heisenbug in C, it's probably NOT:

1. The hardware. 2. The compiler. 3. The OS.

It's not you (compiler), it's me.

masklinn• 12 years ago

When you see a Heisenbug in C, change your mind: it's NOT the compiler. It's you.

Also known as "select isn't broken".

walshemj2• 12 years ago

I have had one large piece of PL1/G code - a whole mess of mappers for a map reduce based billing system where rebuilding the entire code base made one bug go away.

foxhill• 12 years ago

by go away, you of course mean hidden to be found and solved later? bugs do not typically just fix themselves.

dalke2• 12 years ago

Can't say anything about that project, but there could be a build dependency error where a change didn't get propagated all the way through. The "bug" isn't so much a coding bug but a synchronization bug that can be fixed by doing a full rebuild.

For example, on one system I used there was a ~2 second difference between my desktop machine, the build machine, and the NFS host for directory I was working in. This would sometimes lead to:

    make: warning: Clock skew detected. Your build may be incomplete.

If I did a save to a .C file just after the .o file was written, then it might still have a timestamp which was older than the .o, so not included in a rebuild.

This required occasional manual deletes of the .o file to make sure that it was building correctly, and we probably did a full rebuild of the entire code every once in a while to reduce these sorts of problems. (This was back in the c-front days, with 15 minute compilation times.)

dthunt• 12 years ago

Not necessarily.

A decent percentage of the time someone is experiencing a "heisenbug" it's because there are some stale object files sitting around, and the build state has gotten inconsistent (makefile bugs, bad tracking of dependencies, or what have you).

You go to build debug, everything works, you shrug, make clean, remake, and then you're golden again.

Obviously that's really not the way to go, though, because you risk mistaking an uncommon crash for "just had to rebuild, I guess" - but if you're comfortable reading assembly or what-have-you, you can usually confirm the "stale object files" thing easily -

and then fix your build ;)

walshemj2• 12 years ago

Ironically no as dalke comments below I think it mist have been some odd build efect over several hundred modules of code.

chewychewymango• 12 years ago

It's probably worth pointing out that the person with the bug in the story, Jay Maynard, is also Tron Guy.

GFK_of_xmaspast2• 12 years ago

It is not:

1. lupus 2. a tumor 3. a compiler bug

I'm not at all surprised to see ESR being enough of a scrub to go to 'compiler bug!' as his first guess.

fromdoon• 12 years ago

I had once had the opportunity to investigate a heisenbug. We could see that the bug disappeared after turning the optimization off, but our clients were not satisfied and wanted a more detailed explanation and exact root cause analysis.

We were using a proprietary C compiler tool chain provided by our vendor and did not get much help from them either.

Finally, We had to sit down, get the assembly from disassembler and went through whole 800 lines of it. And we found the bug, sitting quietly in one of the pipelines.

I am not a compiler guy, but that day I understood the beauty of compiler optimization.

nitrogen• 12 years ago

A better approach: when you see a Heisenbug in C, run your program through Valgrind's memory and threading checking tools.

kgabis• 12 years ago

I once had a bug in my program where it would work correctly only on -O3 (not quite correctly, but good enough for me to not notice). After a lot of head scratching I ran clang's static analyzer [0] and it found it to be an uninitialized variable. On -O3 compiler was reusing other variable, which happened to be very close to what I needed.

[0] http://i.imgur.com/lqs4FNn.png

ambrop7• 12 years ago

Actually, -g should not change the output of the compiler in any other way than the presence of debug symbols. I can confirm that right here, where I'm building code for an ARM microcontroller, the resulting .bin files produced by objdump are identical (but the .elf are not).

Granted, when the debug symbols end up in the final ELF binary which is executed by an OS, it can still affect execution in subtle ways such as load times.

huhtenberg• 12 years ago

And when you see a heisenbug in MSVC++, just rebuild your project.

I don't know about newer versions, but VS 2010 and priors have a nasty trait of spitting out wrong binary code now and then even when all optimizations off, edit-and-continue and incremental linking disabled. You would just make a little change, build, launch and get a crash in the middle of nowhere with the most bizarre stack trace. Then rebuild it and it will magically go back to normal. For a project of 100k lines this is a weekly, sometimes daily, routine. Very trust inspiring.

grkvlt• 12 years ago

probably just stale object files, hardly unique to MSVC

When you see a Heisenbug in C, change your compiler's optimization level (2010)

Related Stories