Hacker News Reader

Comment by gautamdivgi | Hacker News Reader

“select” Isn’t Broken

So - this one I have mixed feelings about. It is normally true. But you could have genuinely hit upon a bug. Granted it is much easier to investigate and prove with open source today.

14 odd years ago I was working on HP-UX & C applications. One of the signal commands caused things to crash. I finally figured out the test that could cause it to crash. Now HP support seemed to think I was crazy for asking me to debug their code. I took me ages to get them to understand - that the OS was their code and not mine.

Well, either way, they got a tier-3 OS support person involved who collected data, confirmed the bug and provided a fix.

The point is - it may very well be a platform bug. That is code too. It just shouldn't be your first (or may be even second or third conclusion) and you should have a unit test to exercise the bug.

View on HN

When I was a fresh junior programmer (a few years before the book was written), making my first independently designed and significant change to the system I worked on, I tripped over a "select is broken" kind of bug - specifically, mmap() was broken on AIX 3.2.5, in certain cases. It was weird and wonderful, because my code worked in the test environment, but not the production environment.

The response of the senior engineers was "What's really wrong with your code?" Ultimately, I was able to prove an OS bug with IBM, but it required extraordinary proof.

And you know what? If some smart junior programmer came to me and said "I think there's a bug with a low-level OS call", my response would be "What's really wrong with your code?" As it should be. Heck, if a lead engineer said that, I'd have the same response. If I said it, that would be my response to myself.

That's because select is very rarely broken. The exceptions just prove the rule.

I ran across a bug in the JDK when I was an intern and spent 2 weeks documenting and demonstrating that it was in fact a bug in Java not in my code. :D funniest thing was I got to pull an I told you so on my professor who claimed we would NEVER run into a bug in the JDK and to just try to figure out what we did wrong.

Yep. And if an intern of yours came to you and said "I think I found a bug in the JDK", you'd probably say "What's really wrong with your code?", wouldn't you?

But if you're smart, you'd ask him to show you the bug.

If she thinks she found a "select is broken", she needs to write a test to exercise the behavior, independently of our existing code base. That's how I chased down the mmap() bug - I wrote a program that showed the bug on the prod servers but not the test servers, and sent the C code and the executable I compiled off to IBM for analysis. (It was a charming bug, btw... it would randomly overwrite pages of memory with nulls, maybe 10% of the time)

Yep -- minimal demonstrative code. That's the ticket.

"I never make exceptions. An exception disproves the rule."

Finding platform bugs is downright normal on Android. Usually there's already a years-old neglected bug report that's either been marked "wontfix" or (incorrectly) labelled outdated, and closed. If you're lucky there's a workaround in the comments and it's not too gross.

I have mixed feelings about that for a different reason.

"select isn't broken" has been my experience since moving to open source platforms. However I started with VB on Access 2.0. (Yes, this dates me.) And there I found that most of my interesting bugs WERE of the "select is broken" form - Microsoft's software was simply that bad.

I understand that they have improved since then. But the bad taste from that experience stays with me, and is part of why I don't want to deal with the Microsoft stack.

It's "select isn't broken" for a reason. Another way of phrasing it is "What's more likely?". In other words, is it more likely that you and only you have discovered a bug in a very widely used function that's been around for ages, or that you made a typo? In 99.99% of cases, it's the latter.

don't disagree - its much easier to discover that now with opensource and publicly communicated bug databases. What I'm saying is that it is much harder with proprietary software (which is probably a good reason to avoid it in the first place).

I wish I lived in that world. I deal with mobile clients, web browsers, and tls stacks; everything is broken, not just select. I always check to see if it's my software that's broken first, out of hope...

I think it's OK to have advice that isn't always correct in cases like this. By the time you're ready to actually track down and demonstrate an OS or compiler bug, you're ready to move beyond simple advice and think more for yourself.

> you should have a unit test to exercise the bug.

This! Once you've got your test you can start factoring code out of the equation and if you get to the point where your application code is no longer involved, well then that's an OS / library / framework bug but yes that's pretty rare.

Some years ago PHP scripts would crash (without log) if the script file was exactly 1024 bytes. After days of blaming our own code we found out about this bug. No unit test would have figured that one out.

Reply on news.ycombinator.com