47 bytes, text/x-phabricator-request
|Details | Review|
Firefox uses multiple processes. It has intentional leaks, and when running with ASAN, we have suppressions to eliminate those. When running ASAN builds through CI tests, when Firefox exits, each of the processes (parent and child) exits and goes through its leaks and when there are (which is a given), the ASAN runtime runs llvm-symbolizer to symbolicate and match against suppressions. So each process runs llvm-symbolizer. At the same time. Some of the addresses to symbolicate are in libxul. Which contains all DWARF info, making it a ~1GB monster. Oh, and because you're lucky, things align perfectly such that libxul size is a multiple of the page size. That makes llvm-symbolizer pread() the file instead of mmap()ing it. Did I say there are multiple processes? So suddenly you have n processes simultaneously allocating and filling 1GB of memory each, on CI machines that have enough memory for the job they usually run, but not enough for a sudden rush of n GB. And things go awry. When you're lucky and the OOM killer didn't take care of killing the CI entirely, symbolication couldn't happen and the suppressions are not matched, and leaks are reported. This all turns out it originates in how llvm-symbolicate chooses between pread() and mmap(), which turns out is just defaults not being made for binary files.
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/33784a7ae90b Apply https://reviews.llvm.org/D56475 to clang. r=froydnj
You need to log in before you can comment on or make changes to this bug.