[PATCH] D41128: [scudo] Adding a public Scudo interface

[Jonas Hahnfeld via Phabricator via llvm-commits]

Hahnfeld added a comment.

In https://reviews.llvm.org/D41128#965469, @cryptoad wrote:

> I am not sure I understand correctly the question. So I will attempt an answer, and if it doesn't apply, let me know.
>
> If compiled with Scudo, all allocation functions are handled by the allocator (malloc, realloc, calloc, memalign, etc).
>  The soft/hard RSS limit feature comes from a need from some applications to enforce an upper limit to the memory used.
>  This is mostly needed due to the fact that we reserve a large portion of the address space, and as such, setting an rlimit is not viable.
>  The RSS limit comes as an opportunistic, best-effort, check to allow for some type of upper bound check.
>  It is not enabled by default (eg: 0), and it is expansive (a few syscalls to read from /proc).
>  If an application uses directly mmap (or any OS backed memory allocation function), we would only catch a limit "overflow" on the next use of a heap allocation function.
>  Also if we allocate/free some memory backed by the Secondary allocator quickly (before the check interval elapses), we wouldn't catch it as well.
>
> I hope this answers your question.


Yes, that confirms my understanding that the following logic wouldn't be catched:

1. Call `malloc` and allocate all arrays that will be needed.
2. Initialize the arrays - this commits the memory to count as RSS.
3. (Computation on arrays)
4. `free` the arrays.

In https://reviews.llvm.org/D41128#965471, @cryptoad wrote:

> Another point:
>  For ASan, an identical check exists as a background thread. We decided not to do that due to some requirements on Android.
>  It could potentially come back as a background thread check on supported platforms if that would address the concerns you are raising.


This could work although I'm only trying to understand what this sanitizer is able to detect.


Repository:
  rCRT Compiler Runtime

https://reviews.llvm.org/D41128