notes-computer-programming-debugging

" sehugg 3 hours ago

link

Great postmortem and good lessons to learn here:

I'm pretty sure I've repeated this exact same sequence before with similar results... "

"

There is a line from Futurama that perfectly applies ton a lot of debugging.

Farnsworth: My God, is it really possible?

Fry: It must be possible, it's happening.

Fry: By the way, what's happening? "

---

random bugs:

---

" Recent security stories confirm that errors like buffer overflow and use-after-free can have serious, widespread consequences when they occur in critical open source software. These errors are not only serious, but notoriously difficult to find via routine code audits, even for experienced developers. That's where fuzz testing comes in. By generating random inputs to a given program, fuzzing triggers and helps uncover errors quickly and thoroughly. In recent years, several efficient general purpose fuzzing engines have been implemented (e.g. AFL and libFuzzer), and we use them to fuzz various components of the Chrome browser. These fuzzers, when combined with Sanitizers, can help find security vulnerabilities (e.g. buffer overflows, use-after-free, bad casts, integer overflows, etc), stability bugs (e.g. null dereferences, memory leaks, out-of-memory, assertion failures, etc) and sometimes even logical bugs. OSS-Fuzz's goal is to make common software infrastructure more secure and stable by combining modern fuzzing techniques with scalable distributed execution. OSS-Fuzz combines various fuzzing engines (initially, libFuzzer) with Sanitizers (initially, AddressSanitizer?) and provides a massive distributed execution environment powered by ClusterFuzz?. " -- [4]

---

" Change One Thing at a Time On nuclear-powered subs, there's a brass bar in front of the control panel for the power plant. When status alarms begin to go off, the engineers are trained to grab the brass bar with both hands and hold on until they've looked at all the dials and indicators, and understand exactly what's going on in the system. What this does is help them overcome the temptation to start "fixing" things, throwing switches and opening valves. These quick fixes confuse the automatic recovery systems, bury the original fault beneath an onslaught of new conditions, and may cause a real, major disasters. It's more effective to remember to do something ("Grab the bar!") tha " -- ianmcgowan

---

https://rachelbythebay.com/w/2018/04/21/lb/

if one server is failing each request, but failing fast, the load balancer may divert a proportionately large number of requests to that server

---

https://news.ycombinator.com/item?id=27175622

---

Garbi 13 hours ago

link flag

I don’t have all day so I just picked one at the bottom, this one https://blog.nelhage.com/post/a-cursed-bug/ . I didn’t even know that RDMA was a thing and now I’m sitting in the corner hugging my knees and rocking slowly.

    ~
    aidancully 11 hours ago | link | flag | 
    Honestly, fork is more the problem, here, than RDMA is. (And I see that that’s also the name of the text that links there on the iceberg.) fork only works well for private memory mappings in single-threaded processes. Every other process configuration / OS resource is problematic. This issue https://github.com/smol-rs/polling/issues/37#issue-1122097454 we encountered is much less exotic, but a natural consequence of the trouble with mixing “everything is a file” behaviors with “fork”.
    (Also, I’m amused to see that that link describes a bug very much like one we encountered. Our local upshot was that we couldn’t make our system compatible with rsocket, we had to fall back to using libibverbs directly, specifically so that we could control which memory got the MADV_DONTNEED treatment.)

5

---