
Memory Checking - ingve
https://btorpey.github.io/blog/2019/07/14/memory-checking/
======
sigmonsays
this comment largely assumes you know how to create test harnesses to sanity
check your code.

from my experience, while glibc checks are useful, you need to know about more
cases such as overflows, overruns, races, etc. In my experience, I used
valgrind withub a test harness to create the conditions i'd expect.

The glibc approach doesn't seem to compete feature wise with valgrind. It
seems to me that glibc bloat is caused by this.

PS: I have ran valgrind in production, You just have to carefully canary it.

------
MayeulC
Interesting topic. Why not submit a patch to allow the {fast checks, print
error, do not abort} use-case?

~~~
nneonneo
Speaking as someone who exploits programs for fun...that would not be a good
idea at all. Not aborting in the face of _obvious_ memory corruption means
continuing onwards with the memory in some weird state which could cause much
more serious problems later on. And, it makes an attacker’s job a lot easier
if they don’t have to worry about triggering malloc’s checks while gradually
corrupting your heap and taking control of the program through a memory error.

~~~
saagarjha
There are already options that don't abort anyways, unfortunately.

