[PATCH] D33325: [sanitizer] Avoid possible deadlock in child process after fork

Maxim Ostapenko via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue May 23 07:01:33 PDT 2017


m.ostapenko added a comment.

In https://reviews.llvm.org/D33325#761941, @dvyukov wrote:

> I don't completely understand this. allocator_fork_no_hang.cc is broken and deserves deadlocking. Why are we trying to fix this program only under sanitizers rather than detecting and reporting the bug? Sanitizers are meant to be less forgiving than production environment. Why are we trying to conceal the bug?


Yes, the testcase deserves deadlocking (malloc is not async signal safe). And the actual bug is reported here: https://bugzilla.gnome.org/show_bug.cgi?id=738620.
The motivation for "fixing" this in sanitizers is that most of modern allocators (Glibc, tcmalloc, jemalloc) are actually fork safe, so why not to do the same in sanitizers. And despite the fact that calling malloc after multi-threaded fork is not allowed, many people still would expect their code to work (since it works with Glibc/tcmalloc/jemalloc etc).


Repository:
  rL LLVM

https://reviews.llvm.org/D33325





More information about the llvm-commits mailing list