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

[Kostya Kortchinsky via Phabricator via llvm-commits]

cryptoad added a comment.

In https://reviews.llvm.org/D41128#965467, @Hahnfeld wrote:

> Any normal build on CentOS 7 failed reliably. I've submitted https://reviews.llvm.org/D41649 which solves the problem for me, I'll see if this also fixes the failure on ARM...


Cool thanks! Will have look.

> Side note: Do I understand this correctly that scudo will only get active on an intercepted `malloc` and exceeded limits without a `malloc` have no effect? That's a huge restriction, probably most applications in the HPC world first allocate all structures and only start touching the memory afterwards...

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.


Repository:
  rCRT Compiler Runtime

https://reviews.llvm.org/D41128