> SIGSEGV is not the only signal that indicates an error in a process and causes termination. We also saw process terminations due to SIGABRT and SIGILL Also S

> SIGSEGV is not the only signal that indicates an error in a process and causes termination. We also saw process terminations due to SIGABRT and SIGILL Also SIGBUS. To me it happens mostly when playing with mmap and shared memory. But casting random numbers to pointers and trying to access those should do that as well. Don't be too surprised if you see it once in a while. > “BDF76 An Intel® Hyper-Threading Technology Enabled Processor May Exhibit Internal Parity Errors or Unpredictable System Behavior” Lovely. In this sense I've always liked when various layers implement their own checksumming and sanity checking. Don't just rely on hardware to do it (ECC, raid controllers etc). Wrote a database which saves a chunk to disk? Add a checksum with it. Have something that sends data over the wire, send a checksum with it. With disks it's even more fun - periodically read and reverify it as bit rot will slowly eat away at it. Same with backups, verify that your backups can be read and data there is consistent. It's not cheap and you'd pay a penalty for it in performance so it's a tradeoff definitely. Just make sure to consider it and don't forget about it.