mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-10-21 01:05:45 +00:00
a0b6688faa
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. Differential Revision: https://phabricator.services.mozilla.com/D16010 --HG-- extra : moz-landing-system : lando |
||
|---|---|---|
| .. | ||
| aarch64-vastart-checking.patch | ||
| build-clang.py | ||
| clang-3.9-linux64.json | ||
| clang-7-android.json | ||
| clang-7-linux64.json | ||
| clang-7-macosx64.json | ||
| clang-tidy-linux64.json | ||
| clang-tidy-macosx64.json | ||
| clang-tidy-win32.json | ||
| clang-tidy-win64.json | ||
| clang-trunk-mingw.json | ||
| clang-win64.json | ||
| compiler-rt-cross-compile.patch | ||
| compiler-rt-no-codesign.patch | ||
| downgrade-mangling-error.patch | ||
| find_symbolizer_linux.patch | ||
| llvm-debug-frame.patch | ||
| loosen-msvc-detection.patch | ||
| r277806.patch | ||
| r285657.patch | ||
| r289565-for-3.9.patch | ||
| r313872.patch | ||
| r322325.patch | ||
| r322401.patch | ||
| r325356.patch | ||
| r339636.patch | ||
| r342649-hotpatch-8-byte-nops.patch | ||
| r342652-unpoison-thread-stacks.patch | ||
| r343123-pin-asan-dll.patch | ||
| r346300-compiler-rt-windows-mmap.patch | ||
| r350774.patch | ||
| README | ||
| rename_gcov_flush_.patch | ||
| static-llvm-symbolizer.patch | ||
| workaround-issue38586.patch | ||
build-clang.py
==============
A script to build clang from source.
```
usage: build-clang.py [-h] -c CONFIG [--clean]
optional arguments:
-h, --help show this help message and exit
-c CONFIG, --config CONFIG
Clang configuration file
--clean Clean the build directory
```
Pre-requisites
--------------
* Working build toolchain.
* Subversion
* CMake
* Ninja
* Python 2.7
Please use the latest available CMake for your platform to avoid surprises.
Config file format
------------------
build-clang.py accepts a JSON config format with the following fields:
* llvm_revision: The LLVM SVN revision to build.
* stages: Use 1, 2, or 3 to select different compiler stages. The default is 3.
* llvm_repo: SVN path to the LLVM repo.
* clang_repo: SVN path to the Clang repo.
* extra_repo: SVN path to the clang-tools-extra repo.
* lld_repo: SVN path to the lld repo.
* compiler_repo: SVN path to the compiler-rt repo.
* libcxx_repo: SVN path to the libcxx repo.
* libcxxabi_repo: SVN path to the libcxxabi repo.
* python_path: Path to the Python 2.7 installation on the machine building clang.
* gcc_dir: Path to the gcc toolchain installation, only required on Linux.
* cc: Path to the bootsraping C Compiler.
* cxx: Path to the bootsraping C++ Compiler.
* as: Path to the assembler tool.
* ar: Path to the library archiver tool.
* ranlib: Path to the ranlib tool (optional).
* libtool: Path to the libtool tool (optional).
* ld: Path to the linker.
* patches: Optional list of patches to apply.
* build_type: The type of build to make. Supported types: Release, Debug, RelWithDebInfo or MinSizeRel.
* build_libcxx: Whether to build with libcxx. The default is false.
* build_clang_tidy: Whether to build clang-tidy with the Mozilla checks imported. The default is false.
* osx_cross_compile: Whether to invoke CMake for OS X cross compile builds.
* assertions: Whether to enable LLVM assertions. The default is false.
Environment Variables
---------------------
The following environment variables are used for cross-compile builds targeting OS X on Linux.
* CROSS_CCTOOLS_PATH: Path to the cctools directory where the cross compiler toolchain is located.
* CROSS_SYSROOT: Path to the OS X SDK directory for cross compile builds.