3 ms·

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

• nneonneo 7y ago
  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 7y ago
    There are already options that don't abort anyways, unfortunately.
• wallstprog 7y ago
  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 https://bugs.kde.org/show_bug.cgi?id=393926 and https://reviews.llvm.org/D46546 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.