Maybe there’s something wrong with the universe, but probably not


No kidding, I was just walking down a hallway in my building when I overhead the following quite loud conversational fragment through an open doorway:

Angry woman’s voice: “Why are you in the ladies room?! You are the third man to… oh no.”

Like Hobbes, it’s the moment of dawning comprehension that I live for – the exact moment when she realized that she, not everyone else, was in the wrong room was readily apparent. (One wonders what the first two gentlemen did, since clearly they did not successfully disabuse the lady of her error.) Since the building across the courtyard from mine has a mirror-imaged layout, this is a very easy mistake to make if you are visiting from the other building.

I contrast that moment of dawning comprehension with Dr. Crusher’s similar moment in that memorable 1990 episode of Star Trek: The Next Generation when she realizes that she’s not crazy, it’s the entire universe that is wrong. When faced with an absurd and unexpected situation – the gradual disappearance of first the crew and then the entire universe – she at least considers that she’s the crazy one.

Unlike most people, I encounter compiler and library bugs all day long in my job, though mostly ones that I caused in the first place. (Sorry!) But even still, when I am writing “normal” code (rather than test cases designed to break the compiler or regress previous bugs), I try to ensure that my attitude upon encountering an unexpected situation is that I’m the crazy one. Usually it’s my code that is wrong, or my misunderstanding the output, rather than a compiler or library bug.

As the authors of “The Pragmatic Programmer” point out in their third chapter, “select() isn’t broken” – if you are writing perfectly normal code then odds are good you are not the first person to discover what should be an obvious problem in a well-tested product. If you think you’ve found a bug in the math library, maybe you have. Or maybe you’ve actually passed radians to a method that takes degrees, or forgotten to take floating point rounding error into account, or some other such thing. The more obvious the problem, the more likely it is that you’re the crazy one. If the code doesn’t compile and you think it should, it could be a bug in the compiler. But read the error message carefully; it is probably telling you what is wrong with the code.

If you think you’ve found a C# compiler bug, please, by all means bring it to our attention; post it on Connect, or have the community take a gander at it via StackOverflow or one of the Microsoft forums, and if you want, send me a link to the problem. (Please don’t use the “contact” link to send me source code directly; the hostile-email sterilization code that filters that text is very aggressive about stripping out things that look potentially harmful. It makes code almost illegible.) There certainly are bugs in the compiler and the more we get good information on, the better. Including a small-but-complete program that reproduces the problem and the version number of the compiler you’re using is a big help. But first, do stop and take a good hard look at the code and think about whether it is more likely to be a problem with the code or a problem with the compiler. Don’t be one of those people who sends me angry, profane emails about a problem that you caused yourself; that’s just embarrassing.

Comments (31)

  1. Chris B says:

    Ha ha! I laugh because I've was the exact same situation as that unfortunate woman when I was about 14 years old.  In my case, the detective work necessary to figure out why there were no urinals in this particular "men's room" took just a few seconds longer than getting started. Once I had my moment dawning comprehension, I had a difficult decision to make…stop and make a walk of shame to the actual men's room or just finish out.  To this day, I wonder what I would have done if a woman had walked in while I was there.

    On a more on topic note, it's nice to know that you also have moments where the system works correctly albeit contrary to your expectations.  The systems I work on are significantly less complex than a compiler, but I can recall many times where the system has performed non-intuitive action and it takes a few of us a few minutes to realize its not a bug.

  2. Rick Sladkey says:

    I find that this is exactly the mental block that some people have when fixing bugs.  They trust some part of the code and not another part and can't make the mental leap that the problem is in the trustworthy part.  Once they've been burned this way they can actually become paranoid and begin distrust crazy things like addition when other suspects should be considered first.  This is the art of debugging: holding everything you think to be true with some doubt without driving yourself crazy.

  3. Keith J. Farmer says:

    And this is precisely why I've started to insist first that the person claiming there's a bug justify his code.  Once he demonstrates that he's using it correctly to do something reasonably within scope, and that what he's doing actually makes sense for what it is he's trying to solve, we can talk about whether there's a bug.

  4. configurator says:

    I must say, the sentence about "the hostile-email sterilization code" made more sense when I misread it as "the hostile email-sterilization code". Why can't they get that right?

  5. Alex ten Brink says:

    When my program does something wrong, the mistake is nearly always mine, but there is one exception: stackoverflow.com/…/delegate-system-action-does-not-take-0-arguments-is-this-a-c-compiler-bug 🙂

  6. Nat says:

    I always assumed that the more experienced you became, the more likely you were to blame yourself when stuff does not work right.

    I also hate dawning comprehension, as when I slowly realised that the reason the urinals at the sports stadium were strangly high… and wide… and flat… was they were in fact the basins. Not my best moment ever.

  7. Tim B says:

    A man on his way home receives a call from his wife.  "Be careful honey, the news is showing a car going the wrong way on the interstate!"  "One car?" he replies. "Hell, there's dozens of them!"

  8. Rory O'Donnell says:

    I find that using a "Cardboard programmer" to explain the nature of the bug usually solves the "problem".  PS if anybody out there has an unwanted life sized Peter Norton cardboard cutout in good condition, give me a shout.  

  9. Paddy B says:

    Am I the only one that wants to see the particular email that spawned this post?  Redact some personal information and stick it up!

    I've been seeing a number of "select isn't broken" posts on StackOverflow lately. And I've just been meaning to write this sort of thing for a while. Overhearing that unintentional situation comedy moment yesterday provided sufficient activation energy. — Eric

  10. Rob Kent says:

    @Nat, "I also hate dawning comprehension, as when I slowly realised that the reason the urinals at the sports stadium were strangly high… and wide… and flat… was they were in fact the basins. Not my best moment ever."

    This seems to be a common problem with fancy, designer basins. The Dome theatre in Brighton, UK has fancy basins that are basically long, low stainless-steel troughs. I've seen several men walk into there when it's busy, take a pee and as they are doing so, slowly realising that they are just missing the soap dispensers, and yes, they are peeing where the other guys are just about to wash their hands. Amusing.

    Maybe it's just Brighton, but many girls tend to use the men's toilets when there are big queues at theirs. I was in one the other day and a girl just came and squatted on the men's urinal with a bunch of guys standing next to her, and another woman was doing her makeup in the mirror completely nonchalantly. Gender separation in toilets is a recent historical phenomenon so maybe it will just disappear.

  11. Adam V says:

    @Paddy B: Eric did recently reference "select isn't broken" in his reply to this question on StackOverflow:

    stackoverflow.com/…/c-bug-in-threading-task-parallel-for

    What I find interesting is Eric's comment on the answer: "I assure you that there is a bug in the library. It's just that this isn't it."

  12. Erik Forbes says:

    You don't happen to know the name of that star trek episode, do you?

    You'll note that I put a convenient "hyperlink" to the Star Trek wiki. If you click on that link, you'll get information about the episode. — Eric

  13. Mike Strobel says:

    I always start out by assuming that the problem is with me and not the compiler.  It's usually a safe assumption, except for that one time when I actually did find a bug in the C# 4 compiler.  The BadImageFormatException suggested very strange was afoot :).  Thanks again for checking it out for me, and for your detailed explanation (it was the generic virtual iterator bug).

  14. Mike Strobel says:

    @Erik: "Remember Me" (Star Trek: TNG, Episode 4×05)

  15. Ken says:

    My experience tends to be "you're not the first person to try this, but the universe is indeed broken".

    I'll struggle with something for a little while and then STFW and find that a bunch of other people have run into exactly the same bug, sometimes years ago, with no fix in sight.  🙁

  16. Fred says:

    A good article, but every now and then it turns out you've been blaming your own code, banging your head against a brick wall and select WAS broken!

    My recent example: The .NET microframework where double.Parse("-0.1") really does return +0.1. A pain to find when your GPS based project only gets screwy when you're near the Greenwich meridian!

  17. What if I know I'm crazy to begin with? says:

    What if I know I'm crazy to begin with? Am I just screwed?

  18. Joe says:

    About 15 years ago, I had a guy working for me who wanted to call a company not named Microsoft every week because of a bug in their C compiler. Every time, he either misspelled something or forgot a closing brace in the C code. I was ready to take his phone from him.

  19. Jonathan says:

    I agree that the compiler/library probably handles correct code correctly, and if the program doesn't work there is probably a problem with the code. But if incorrect code produces errors that don't indicate what is wrong with the code, I say the compiler/library also has a problem.

  20. Jason Lind says:

    I've found very few real bugs in the C# compiler, what I have run into more often is arbitrary limitations that are actually buried in the specification that conceptually shouldn't be there, which is what Microsoft I guess refers to as a "design feature". So the universe is normally accurate I guess but that doesn't necessarily make it right.

  21. Gabe says:

    My first problem with the universe was back in the early 90's with a file listing/manipulaiton program I wrote. At some point, it started crashing upon exit when the number of files in a directory was a multiple of 3! After bashing my head looking for the usual memory corruption problems, I swapped a couple irrelevant lines in the source code and the problem went away. I seem to recall that at some point the problem came back and I had to swap the lines again. I never did figure out if this was a codegen bug in the C++ compiler, but it seemed too strange to be a bug in my code.

    The problem with a bug like this is that it's nearly impossible to get a minimal reproduction because it's brought about by random perturbations within 100,000 lines of source code.

    While I've encountered several bugs in various parts of the .Net environment, I have yet to have the pleasure of finding a bug in the C# compiler.

  22. Bryan says:

    Kudos on the Trek reference.  How 'bout an article on small API changes from version to version and compare it to the episode where Worf is shifting between parallel universes every time he comes in proximity of Geordi's visor?

  23. @Jonathan: generally speaking, good error detection and reporting is a good idea. The problem is that, at times, it can be too expensive, especially when most API clients are never going to hit the error case – yet pay the price for error checks.

    Sometimes it's a trade-off. VB throws on arithmetic overflow by default on all integral types – handy for detecting those pesky overflow bugs, but you get checks sprinkled throughout your code for every arithmetic op, most of which will never ever hit it in practice. C# does unchecked arithmetic by default, and you have to use /checked+ to enable that. Which one is preferable?

  24. Jonathan says:

    @Pavel: Most of what I am complaining about is that when an error is reported, the information about what caused that error report is thrown away instead of being encoded into the error message.

    See these bug reports:

    connect.microsoft.com/…/system-badimageformatexception-is-not-informative

    connect.microsoft.com/…/typeloadexception-the-signature-is-incorrect-needs-more-information

    Due to Microsoft's refusals to fix these problems, and rediculous use of NotSupportedException in derived classes of Type related to generics and emitted types, I am writing my own library to replace System.Reflection.Emit.

    In another library that I provide, I use produce two versions, a developer version that does agressive error checking and gives informative error messages, and a release version that assumes the calling program is correct.

  25. Ted says:

    Please address when VS 2008 will get SP2 given that SP1 was released Aug 2008 (over 2.5 years ago). Can we also get XP SP4 since SP3 was released May 2008 (3 years ago).

    It's important to us since getting a multi-man year effort approved to do a full retest of one of our larger systems is not possible. Our core systems each have from 200,000 to 750,000 lines of .NET code.

    You're asking the wrong guy; I know nothing whatsoever about service pack scheduling. And even if I did, which I emphasize I do not, I can't talk about schedules of unannounced releases. Sorry! — Eric

  26. Dan says:

    @Bryan That post approaches theoretical maximums for nerdiness. I salute you, sir!

  27. CarlD says:

    @Ted

    It's pretty safe to assume:  

       VS 2008 SP2:  Never

       Windows XP SP4: Never

    Plannning on anything different is foolhardy at best.

  28. Phil says:

    Interesting, the world sent you to tell me that I and not it is wrong. What is this world coming to?

  29. DaveShaw says:

    Someone at my office is still trying to convince me that a bug in our product is because an uninitialised Guid field is not equal to Guid.Empty and it must be a compiler problem, and/or that he should compare the uninitialised to the string "0000-0…".

    I might have to send him this article – although he may just mail you Eric with his theory – so maybe not 🙂

    *I think the reason for his crazy assumptions is because the version the on the customer's machine is not the same as the source he's looking at.

  30. Rudy Steinhoff says:

    One of the cuious traits I have always dones is to "act as if" you know and then start programming. As a manager and veteran coder I now see more and more developers who get stuck or think they are crazy.  I offer a mindset trick that says act as if you have already solved the problem and proceed.  That is not to say you dont do your research and try to figure things out, but often I find developers on my team who wait until the answer comes to them.  Get past that and often you will see the forest for the trees.

  31. Timwi says:

    I appreciate how you appear to welcome reports of bugs in the compiler.

    I would appreciate it more if these bug reports were actually welcome. So far all of them, (http://connect.microsoft.com/VisualStudio/feedback/details/594344/) fatal bugs that silently generate crashing programs, have been marked as won’t fix or otherwise been considered unimportant or unworthy of any attention.

    It makes us normal people wonder what the point would be in reporting anything (which is no small amount of effort, creating a minimalist test-case and writing up the report). And it makes Microsoft appear hypocritical if one part keeps asking for bugreports and the other keeps rejecting them.

    First off, we do very much appreciate bug reports, so thank you for them.

    Second, we do go through and triage all the bug reports we get from Connect. We have many, many thousands of bugs and other issues that we track and not all of them can get a long, personalized reply. They all get attention, but that is not always apparent to the reporter, I know.

    Third, it looks like you and Alex are having a reasonable discussion regarding the particular bug you linked to; this is evidence that the system working. It's not always clear to us what is an obscure and unlikely bug, and what real developers run into in real code. We prioritize the latter much more highly. Your explanation of how you came across this helps a lot.

    Fourth, I've gotten the feedback I just got from you — that Connect feels like a black hole into which issues and suggestions are being poured, to no effect whatsoever — from a considerable number of developer customers over the past couple years. The problem isn't technical; this is a case of the design of the tool not matching the social or emotional expectations of the people using it.

    This shortcoming is particularly vexing because (1) the dissatisfaction is irritating a very valuable set of customers: those like you who take time out of their busy days to help us improve our products, and (2) because that impression is totally false. We get great value out of having that stream of issues and suggestions, and it really does improve the product.

    The community PMs are trying to figure out how to deal with the shortcomings of Connect in a way that we still get value out of the site. It is a slow process and a hard social-software-design problem to solve. Like Alex said, if you have suggestions for ways to make it better, try posting them on Connect! (The irony is palpable, I know.)

    — Eric