5 ms·
Some of the things "I've learned in 25 years": After arguing with a friend who claimed to have discovered a bug in `malloc` because his program crashed (that w
by zvrba 7y ago
Some of the things "I've learned in 25 years":
After arguing with a friend who claimed to have discovered a bug in `malloc` because his program crashed (that was a long time ago), I figured that there's a hierarchy of probable causes of bugs, from most probable:
1. The code I wrote [you must understand only your code]
2. A 3rd-party library/dependency [you must understand your dependencies]
4. The compiler [you must understand the compiler-generated code]
5. The OS, or OS-provided library [You must be intimately familiar with OS internals]
6. CPU, or other hardware-related [You must be intimately familiar with how the CPU or other HW works]
It's basically arranged according to how many other programs are using the given facilities. Returning to the "buggy malloc", I did not dismiss his theory outright just pointed out that if malloc were bugged in such an elementary fashion, that no other programs could work, hence there was overwhelming probability of his code being bugged, not malloc.
---
Just like security features, error-handling cannot be bolted on afterwards. Robust programs begin with defining error-handling strategies and expected outcomes in case of errors and building the rest on top.
---
I could probably go on, but... meh.
- faanghacker 7y agoLOL reminds me of the time at work when I was helping a fellow SWE deploy his code to a new platform. It didn't work. He immediately blamed the it on the fact that we were using a new platform. I then noticed that we were also deploying a newer version of his code onto this new platform, instead of the old code that was known to work on the old platform. I asked him how he knew it was because of the platform (#5 or #6) and not the newer version of his code (#1). Turned out I was right. And this was his code, not mine. The best part? He had been on the team longer than I had, and this was at Google of all places. And people wonder why I have lost interest in the field...
- dchichkov 7y agoAnd sometimes. Yes. It is just a bug in a malloc. And you can fix it. And it wouldn't be there any more. And cool thing, you can even brag a bit that you've fixed bug in a malloc. By the way, there was sort of a bug in a malloc I remember fixing. Now, when was it. Ah, on 7th October 2006 ;) https://gitlab.flux.utah.edu/gtw/git/blob/dff9d65dc61af8a00a6eef153ebc59b76de9c412/compat/nedmalloc/Readme.txt https://gitlab.flux.utah.edu/gtw/git/blob/dff9d65dc61af8a00a...
- GuB-42 7y agoThe bug in malloc() is an old classic. From my experience (about 20 years): 1- Obviously... 2- Some libraries are more reliable than others. 3- Missing, are you working for Valve? 4- I sometimes encountered compiler bugs, but it was things like compile-time crashes, never bugs in the generated code. 5- Never happened to me. Or at least no bugs that weren't documented (there is a BUGS section in manpages, read it). 6- Actually more common than the previous two. In fact extremely common in the embedded software business. But even with PCs, bad RAM sticks and things like that happen.