A C Heisenbug in the wild

http://jacquesmattheij.com/a+C+Heisenbug+in+the+wild

by Swannie • 15 years ago

26 29 15 years ago

jacquesmattheij.com

Swannie2• 15 years ago

I think "Side effect free" in assert() is the biggest takeaway from this.

jesstaa• 15 years ago

Avoiding this kind of bug is one of the reasons why Go doesn't have assert().

_delirium• 15 years ago

A C compiler could warn on large classes of side-effecting code inside assert(), as he suggests, but it'd be tricky to decide exactly which kinds of side effects to warn on to avoid too much noise. At the very least, I/O stuff would probably have to be excluded, or else you'd spuriously warn on the common pattern of dumping some debugging info to stderr within a call like assert(everything_ok()).

abcd_f• 15 years ago

Trivial stuff, really. Useful to know - sure. Worth several pages of the blog post - hardly.

Now let's see the HN fanboism in action. It is Jacques' after all.

JoachimSchipper• 15 years ago

You're not necessarily wrong, but try being less nasty about it.

barrkel2• 15 years ago

This is why the Delphi compiler codebase (written in C) uses two functions, "invariant()" and "invariant_if_debug()", instead of library-supplied asserts. The second gets compiled out in release; the first triggers internal compiler error diagnostic even in production.

xxpor2• 15 years ago

I was under the impression that Delphi was written in Delphi.

barrkel2• 15 years ago

The Delphi IDE is written in Delphi, but the Delphi compiler is written in C.

Cushman• 15 years ago

I don't mean to be that guy, but this is the sort of bug that makes me wonder about the state of professional programming. Even if you're not fluent in C, as a programmer it should be intuitively obvious what's going on here.

Of course we all have brain farts now and then, but there's no way this code should survive a second, let alone a third reading.

Or am I just being conceited?

schrototo• 15 years ago

I thought the same thing, as bugs go this one seemed rather trivial. Having said that, it is tremendously easy to overlook even the most obvious of errors in code you yourself wrote, even and especially when going over it multiple times.

alexgartrell2• 15 years ago

It's non-obvious that asserts would just be #define'd out of existence when NDEBUG is defined if you haven't been told that specifically.

to3m2• 15 years ago

As you might be told specifically by, for example... the documentation?!

The biggest surprise for me is that this error survived more than one attempt to remove it...

leot4• 15 years ago

Why bother having assert statements at all in a language if they're going to stick around in production code? If you're actually worried about something actually going wrong you shouldn't be looking to an assert statement (but, instead, probably a straight condition).

bch2• 15 years ago

I get that assert() is a macro, but how does that affect the scope of char *p that it "works" in one case and segfaults (as I'd expect) in the other?

bch2• 15 years ago

OK -- I wasn't looking at this clearly. In case there are others like me:

  * the scope of *p is only global. My comment re: scope is just Wrong.
  * there is never a call to someinitialization() *execpt* via the assert. If no assert() is called, the Bad Value prevails; if the assert() is called, it resets *p.

I feel a bit foolish, but found it easy to misread this at first glance. If anybody else didn't get it initially, hopefully this helps :P

I thought there was deeper magic, but it's really just programming flow, and knowing good practices re: assert() (or anything that has side effects).

vicaya• 15 years ago

I don't think so. At least 4 companies' codebase have their own assert/contractual macros specifically for this reasons. Such code will never pass a cursory review at these companies. This is a C-noob bug, IMO.

zerd• 15 years ago

This is why we should read man pages:

man assert: "This may create Heisenbugs which go away when debugging is turned on."

icecommander• 15 years ago

The Python analog would be something like this:

assert (object() < object()) == False

(try running this in the interpreter a few times)

coconutrandom• 15 years ago

Woah... so this is coercing it to a string and the address in hex is being compared. Am I off on this?

leot4• 15 years ago

Yes. Python is not that mysterious.

For generic objects, the __lt__ and __gt__ methods are simply defined the only way that's sensible, which is effectively as a pointer location comparison.

leot4• 15 years ago

Not really.

The example given is equivalent in badness to:

  g = Timer()
  assert g.startTimer() == 0

... and then wondering why the timer doesn't start when you run your program in "optimized" mode.

newobj• 15 years ago

That's not a Heisenbug. That's just a classic newbie mistake. If it's made by a non-newbie, then I highly question their competence.

ootachi• 15 years ago

This is the reason why I think it would be preferable for assert() to use eager evaluation. Any optimizing compiler will optimize away the useless check if debug mode is off, even if function calls obscure it (as long as the compiler can reason about purity).

A C Heisenbug in the wild

Related Stories