I have a vaguely related story of a baffling segfault bug a few months ago. It was in some reference-counting code deep inside the Boost shared pointer implementation. It wasn't deterministic, and from correlating the crash log with the Boost code, i couldn't see how there could be a dodgy memory access at that point. Poking around with GDB, it seemed fine.<p>Eventually i realised that i had compiled my application against one version of Boost, and then dynamically linked to a library i had compiled against a different version. This was all due to bad library path hygiene - my OS had one version of Boost installed, and i was trying to use another that i had installed locally, but GCC was ignoring my path options and getting seduced by the system Boost. After this, i learned about the --sysroot flag to GCC, which has helped to prevent this happening again.<p>So yeah, protip: know what it is you're actually running. Also, never use C/C++.
<i>But GDB is not to blame, modern compilers, with optimizations turned on, generate code that can hardly be matched back to the source code.</i><p>In my experience, GDB should get some blame at least --- far too many times I've seen it fail on code of the form<p>var = foo();<p>where the value of var will clearly be in the return value register after executing the function call, but GDB steadfastly refuses to display var, claming it's been optimised out and unavailable. Inspecting eax/rax clearly shows the value is available.
While often convenient, adding “extra credit” to an otherwise focused commit can create a lot of confusion later on. It also makes the commit harder to understand (what does that line have to do with this fix?).
> You can never detect a read overflow otherwise: it will just access data outside your structure, but inside mapped memory, so the bug would be totally harmless and silent, with the exception of doing the same operations at the end of the mapped region.<p>Unless you use one of the sanitizers while fuzzing, right? If not ASan then I would wager MSan could detect this.
Great article, bonus points for giving in passing the only explanation I have been able to understand on what a fuzzer check is and by extension how unrelated tools like QuickCheck should work.
Any recommendations on how to learn x64 assembly? I’d love to be able to throw a piece of code in godbolt and be able to understand the disassembled code.