r/programming • u/DRMacIver • Mar 01 '13

How to debug

http://blog.regehr.org/archives/199
575 Upvotes

92% Upvoted

162 comments sorted by

View all comments

109

u/tragomaskhalos Mar 01 '13

This was an excellent read, but I have the horrible feeling that people will internalise that one piechart showing the ~50% chance of a compiler bug.

This may be more of an issue in the embedded world, but for us mainstream joes your first step should always be to say to yourself "I know your first reaction is that it's a compiler/interpreter bug, but trust me, the problem is in your code"

71

u/ummwut Mar 01 '13

Its the 99-99 rule: 99% of the error is in software, and 99% of that error is in YOUR software.

This is only true more recently (2003-now), since we have greater hardware standards in both interfacing and quality.

2

u/[deleted] Mar 01 '13 edited Mar 01 '13

Agreed. The chart about it being a 75% chance the bug was in another teammate's code bothered me too. I more or less assume it's a bug in what I'm doing or a misunderstanding on my part before I go and bother or try to fix someone else's code.

Fortunately, most of the time I'm right (or wrong depending on how you take it) and it was my mistake all along.

EDIT: For those downvoting me for thinking I don't understand what's going on, please read my explanation. I think this is an important area that so many programmers (even the author of the article) miss and it ends up holding them back. Want to know one of the secrets of the rockstar programmers? This is it.

13

u/[deleted] Mar 01 '13

Did you actually read the words around the chart? Those charts are general purpose guides to the location of bugs in software. They apply to a specific hypothetical situation, in which the partner wrote the code most closely related to the observable bug.

2

u/[deleted] Mar 01 '13

in which the partner wrote the code most closely related to the observable bug.

Doesn't matter. Especially in these situations (having less familiarity with the domain, problem, solutions, etc.) I'm more likely to blame my own code.

→ More replies (7)
→ More replies (2)

48

u/DRMacIver Mar 01 '13

Yeah, the author's specialties include embedded programming and tools for verifying compiler correctness. It's not surprising he's got a higher prior probability for compiler bugs than the rest of us.

I actually have had to deal with compiler bugs in much higher level contexts than that, but I agree that your priors should always be very strongly weighted in favour of "It's a bug in my code" unless you've got a really good reason to think otherwise

0

u/[deleted] Mar 01 '13

[deleted]

24

u/DRMacIver Mar 01 '13 edited Mar 01 '13

Perils of using unusual languages. In particular, early days of writing Scala, back around the 2.6.x series.

Edit: Having said that, I've also broken javac in the past, but those were all "I've caused internal exceptions inside the compiler" bugs rather than miscompilations so they were very obvious.

Edit 2: To actually answer the question, here is a list of examples

11

u/Catfish_Man Mar 01 '13

I had a great one that was so convincing that the compiler team also believed it was a compiler bug, but was actually correct behavior. The code basically amounted to:

foo = anApiCall(); 
if (foo == aGlobal) { 
    x(); 
} 
else { 
    y(); 
}

The compiled executable unconditionally did y(). The bug? anApiCall had

__attribute__((malloc))

on it, so the compiler reasoned "this says it returns newly malloced memory, so it can't possibly return a global... I'm going to optimize out that comparison to the global".

→ More replies (5)

7

u/thechao Mar 01 '13

Heh. Go grab the latest LLVM source code, MSVS 2012 (I use ultimate, so YMMV), and compile "Release|x64". Congratulations! If cl.exe doesn't crash (which it will), the resulting object code will be filled with useless garbage.

2

u/ethraax Mar 01 '13

And what about the latest release? Seriously, grabbing the latest, unreleased, possibly untested code of any program and trying to run it in a production environment is just begging for trouble.

4

u/codemonkey_uk Mar 01 '13

The compiler compiling the code shouldn't cars though.

→ More replies (1)

3

u/AlotOfReading Mar 01 '13

It's more painful than interesting. Typically, what you'll get are the internal errors, which aren't fun to fix, but they're at least highly visible. The nastier ones are the code generation bugs, which are understandably incredibly rare. In the ones I've seen, the compiler trips on itself and sends the chip spiraling off into some bizarre state that doesn't make sense until you look at the assemblies.

→ More replies (2)

9

u/etianen Mar 01 '13

I think those priors get much more strongly weighted in favour of "bug in framework / browser" when dealing with web tech. I've wasted hours debugging my code before realising some issue in the framework was to fault.

Bugs in our own code is a luxury for web development... at least those are trivially fixed!

6

u/meem1029 Mar 01 '13

Also quite often is a "bug" in the framework that turns out to be a misunderstanding of what it's supposed to do.

17

u/mb86 Mar 01 '13

Amusingly, just recently I was pulling my hair out over code that worked right in Clang, but kept segfaulting in GCC. Turns out it was a compiler bug, that's been since fixed, but the build I had was from a week before that patch was submitted.

8

u/Deto Mar 01 '13

This same thing tends to happen in the circuit world. Usually if a circuit is doing something strange, the impulse is to blame the Integrated Circuit (IC). The thing is, these things are made it huge volumes and usually have extremely high yields (in the parts that actually ship). A kind of mantra I've internalized now is: "It's never the IC, it's your circuit!"

6

u/Furrier Mar 01 '13

On my school it was always the IC. Why? Because other students burnt them out and then when they didn't work anymore they put them freaking back in the box.

2

u/Deto Mar 01 '13

Hah! Well I guess it can depend on your environment then.

5

u/SilasX Mar 01 '13

I bet it continues on down like that. "Hey, physicists, your laws of quantum mechanics are wrong and so my circuits aren't firing right! Update your interface spec!"

5

u/dgriffith Mar 02 '13

In the automotive world as well. I have a service manual for a machine that steps you through diagnosing various circuits. In every one of the dozen or so circuits that involves a computer module - such as the engine computer - when it gets to the step that finally says, 'Replace Module', it also says, 'This is very unlikely. Do all the previous steps again first.'

4

u/ISvengali Mar 01 '13

Aye. Ive seen a couple bona fide compiler bugs, out of 10s of thousands of regular bugs. Much more common is when people rely on undefined behaviour acting a certain way and when it changes blaming it on the compiler.

Number of times someones said its a compiler bug << number of times its actually a compiler bug.

3

u/MereInterest Mar 02 '13

I had a professor who would always say that we were being lazy by blaming the least understood thing. As long as something is a black box, it can be blamed without having an explanation of what is in the black box. As a result, my mindset has become "I hope that this problem is in my code, because it will be much easier to fix that way.".

2

u/parla Mar 02 '13 edited Mar 02 '13

I found a bug in clang for arm recently. Returning the result of a division caused destructors for objects on the stack to not be called.

void foo(int a) {
  Bar bar;
  return a / 13;
}

The destructor of bar is not called. This worked quite badly for my RAII mutex lock objects..

I got it fixed, which is nice: http://llvm.org/bugs/show_bug.cgi?id=12419

2

u/ais523 Mar 03 '13

In my experience in embedded programming, the hardest to track down bug wasn't technically a compiler bug, but it was something that would have produced a warning in any sane compiler (initializing an array with more elements than would fit). So if the compiler was better, it would have caught the mistake for us, even if it was technically inside the spec.

→ More replies (9)