Memory Checking

btorpey.github.io

50 points·ingve··5 comments

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.

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

I've had little success with that in the past -- I've submitted patches for both valgrind and AddressSanitizer which have gone nowhere. (For the record these are https://bugs.kde.org/show_bug.cgi?id=393926 and https://reviews.llvm.org/D46546 -- feel free to upvote them!)

I suspect the same would happen with glibc. To be fair, the maintainers for these packages have a lot on their plates, and tend to pay more attention to submitters who they see often, so one-shots like these just don't bubble up to the top.

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.

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

Reply on news.ycombinator.com