Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Anatomy of a Compiler Bug

mikeash.com

Post reply on HN
Print view View original

11–20 of 21 posts

Re: Anatomy of a Compiler Bug

#11

Post by sanderjd »

mikeash wrote: post #5
sublimit wrote: post #3

Haha, it's almost like some detective short story. Surprisingly it wasn't as hard to follow as I thought. Maybe I'm starting to get good at this Computer Science thing.

Must be my fantastic writing. Seriously though, assembly isn't all that hard, mentally. It's difficult in the same way that unloading a truck full of sand with your bare hands is difficult. Which is to say, it takes a long time, but all it really needs is time, not deep thought. People get scared away from it because they don't know where to start with it, or because it looks really hard, or because it just takes too…

I think the hard part mentally (that your incredibly great explanation completely alleviated) is trying to guess at the meaning of the interplay of all the instructions, addressing modes, register overlaps, and calling conventions. It seems like the only way to turn that from difficult (impossible) guess-work to mere sand-unloading drudgery is to either have a lot of it memorized already, or to have a very strong command over the various documentation resources.

Re: Anatomy of a Compiler Bug

#12

Post by ryanmolden »

sublimit wrote: post #8
mikeash wrote: post #5

Earlier quoted context omitted.

Must be my fantastic writing. Seriously though, assembly isn't all that hard, mentally. It's difficult in the same way that unloading a truck full of sand with your bare hands is difficult. Which is to say, it takes a long time, but all it really needs is time, not deep thought. People get scared away from it because they don't know where to start with it, or because it looks really hard, or because it just takes too…

Or because they don't see immediate value in it, as typical programming isn't done in ASM nowadays. I think it's worthwhile just to "demystify" computers, but since embedded programming, demos and retro gaming are part of my interests, I get practical benefits out of it as well.

True, but when it comes in handy it can be immensely so. I was looking at a customer crash dump at work the other day and the callstack shown by two different debuggers didn't make any sense, it was showing calls sequences the code clearly didn't make. Looking at the raw stack in memory and using the disassembly to help see the layout of the frames made it (relatively) easy to see there were a couple of calls in the sequence that both debuggers simply weren't showing. Once I had the real sequence and the dissassembly to see how the frames evolved and recompute call targets for earlier in the frames life it became a lot easier to see what was going wrong. If I hadn't been able to do that (and my ASM skills are definitely not strong) this would have been a No Repro (and hence no fix) bug for sure.

Re: Anatomy of a Compiler Bug

#13

Post by asveikau »

iso8859-1 wrote: post #10
CountHackulus wrote: post #7

I used to work on compilers, C/C++, COBOL, PL/I, Java, a whole bunch of them. This is actually somewhat similar to my favorite bug I encountered while implementing some stack mapping optimizations. The compiler itself was crashing out while compiling a SPEC2000 test case (perlbmk I think?) with an illegal instruction. This was already quite suspect since it was branching to somewhere WAY outside of where the program…

Why doesn't the standard library warn when it knows %Lf might be too long?

sprintf does not know the size of the destination buffer. That's why the newer snprintf, which takes a size as a 2nd parameter, is recommended.

(I say newer, but according to manpages snprintf is defined by SUSv2, from 1997, and C99, from 1999; so they're pretty old by now.)

You could probably have the compiler warn, provided (1) the destination is still an array and not a pointer (2) the format string is known at compile time. But that's a very different thing. (Most compilers these days do warn about any calls to sprintf, recommending snprintf instead.)

Re: Anatomy of a Compiler Bug

#14

Post by asveikau »

CountHackulus wrote: post #7

I used to work on compilers, C/C++, COBOL, PL/I, Java, a whole bunch of them. This is actually somewhat similar to my favorite bug I encountered while implementing some stack mapping optimizations. The compiler itself was crashing out while compiling a SPEC2000 test case (perlbmk I think?) with an illegal instruction. This was already quite suspect since it was branching to somewhere WAY outside of where the program…

> that platform doesn't have an snprintf (yay mainframes!)

One trick I did once when I wrote code somewhere that didn't have snprintf: create a pipe, fprintf into it, and only read at most N bytes back.

It worked and was portable but I'm sure the performance was horrible; this wasn't anything professional, I was just messing around as a kid (back when it was more common to come across platforms that hadn't gotten to SUSv2 or C99 yet). Probably a better solution would be to steal an implementation from an open source libc.

Re: Anatomy of a Compiler Bug

#15

Post by limmeau »

Thanks for sharing -- I love puzzles like that.

Just curious: Were the lldb session snippets taken from the original debugger session? I keep getting weird looks when I use a command-line debugger just to have a transcript afterwards. (The weird looks being from people who'd rather send me a screenshot of their GUI debugger's call stack.)

Re: Anatomy of a Compiler Bug

#16

Post by zwp »

asveikau wrote: post #13
iso8859-1 wrote: post #10

Earlier quoted context omitted.

Why doesn't the standard library warn when it knows %Lf might be too long?

sprintf does not know the size of the destination buffer. That's why the newer snprintf, which takes a size as a 2nd parameter, is recommended. (I say newer, but according to manpages snprintf is defined by SUSv2, from 1997, and C99, from 1999; so they're pretty old by now.) You could probably have the compiler warn, provided (1) the destination is still an array and not a pointer (2) the format string is known at co…

> newer snprintf

Also see C11's sprintf_s() and similarly-named friends.

Re: Anatomy of a Compiler Bug

#18

Post by asveikau »

asveikau wrote: post #14
CountHackulus wrote: post #7

I used to work on compilers, C/C++, COBOL, PL/I, Java, a whole bunch of them. This is actually somewhat similar to my favorite bug I encountered while implementing some stack mapping optimizations. The compiler itself was crashing out while compiling a SPEC2000 test case (perlbmk I think?) with an illegal instruction. This was already quite suspect since it was branching to somewhere WAY outside of where the program…

> that platform doesn't have an snprintf (yay mainframes!) One trick I did once when I wrote code somewhere that didn't have snprintf: create a pipe, fprintf into it, and only read at most N bytes back. It worked and was portable but I'm sure the performance was horrible; this wasn't anything professional, I was just messing around as a kid (back when it was more common to come across platforms that hadn't gotten to…

Not sure why that was downvoted. I'm sorry I offended you, downvoter, but in my defense I've seen much more inane comments not downvoted here.

Re: Anatomy of a Compiler Bug

#19

Post by asveikau »

zwp wrote: post #16
asveikau wrote: post #13

Earlier quoted context omitted.

sprintf does not know the size of the destination buffer. That's why the newer snprintf, which takes a size as a 2nd parameter, is recommended. (I say newer, but according to manpages snprintf is defined by SUSv2, from 1997, and C99, from 1999; so they're pretty old by now.) You could probably have the compiler warn, provided (1) the destination is still an array and not a pointer (2) the format string is known at co…

> newer snprintf Also see C11's sprintf_s() and similarly-named friends.

This is one area where C11 seems like it solves pointless non-problems. snprintf() is not all that "unsafe" in that it does do a bounds check, and the C99 version is clear about saying that the null terminator is included in the count. I also like the error conditions of C99 snprintf() better - it's more interesting to know the exact size required than it is to know that my buffer is not big enough.

Re: Anatomy of a Compiler Bug

#20

Post by mikeash »

comex wrote: post #17

Nice article. But I wish it had gotten into an explanation of the actual bug in LLVM's code. Anyone have a bug number?

I wanted to get into that as well, but ran out of brainpower. This is supposedly the revision that fixes the bug:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-...

Would love to hear your conclusions about what the ultimate cause was if you get that far.

Post reply on HN