This bug's crashes are definitely caused by a bug in LLVM 21. I'm able to trigger them in a local mozilla-central build made using `clang` and `lld` from LLVM 21. This happens with LLVM 21.1.2 as used by Nix, and also with the latest release (LLVM 21.1.4). They don't happen with LLVM 20. Which should be good news to those working on bug 1923255. Source and binary distros for LLVM are available [here](https://github.com/llvm/llvm-project/releases). But there are no macOS binaries for LLVM 21 -- only for LLVM 20. So I had to build them myself, which was a royal pain. [llvm.org's build instructions](https://llvm.org/docs/GettingStarted.html) are incomplete and misleading, so I think it's worthwhile documenting how I built LLVM 21. The basic commands I used were as follows. I first installed Homebrew's `cmake` and `ninja`. ``` cmake -S llvm -B build -G Ninja -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra;lld" -DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi;libunwind;compiler-rt" -DCMAKE_BUILD_TYPE=Release -DLIBCXX_ENABLE_VENDOR_AVAILABILITY_ANNOTATIONS=ON ninja -C build all ninja -C build install ``` LLVM recommends building in two stages -- first using the Apple compiler and linker (`clang` and `ld64`); second using the LLVM compiler and linker (`clang` and `lld`) that you just installed. I did this. For the first stage I used an additional parameter (for example `-DCMAKE_INSTALL_PREFIX=/staging/directory`) to install into a staging directory. For the second, I temporarily put the staging directory at the start of the path: For example `export PATH="/staging/directory/bin:$PATH"`. And I changed the install prefix to point to something more permanent -- for example `-DCMAKE_INSTALL_PREFIX=/usr/local/llvm-project-21.1.4`. For this you need (of course) to use `sudo ninja -C install`. To get `./mach configure` and `./mach build` to use the "wrong" version of LLVM, I changed the `clang` and `lld` shortcuts in `~/.mozbuild/clang/bin`. `./mach configure` fails using LLVM 21. I needed to specify `./mach configure --without-wasm-sandboxed-libraries`. And for both LLVM 21 and 20 I needed to patch trunk code as follows: ``` diff --git a/third_party/zucchini/chromium/components/zucchini/suffix_array_unittest.cc b/third_party/zucchini/chromium/components/zucchini/suffix_array_unittest.cc --- a/third_party/zucchini/chromium/components/zucchini/suffix_array_unittest.cc +++ b/third_party/zucchini/chromium/components/zucchini/suffix_array_unittest.cc @@ -22,7 +22,8 @@ using SLType = InducedSuffixSort::SLType } // namespace -using ustring = std::basic_string<unsigned char>; +//using ustring = std::basic_string<unsigned char>; +using ustring = std::vector<unsigned char>; constexpr uint16_t kNumChar = 256; ``` I found valuable help [here](https://github.com/llvm/llvm-project/issues/155606#issuecomment-3339648510) and [here](https://gist.github.com/hoyhoy/492cf3077239baececb6b838bf620d39). This is where I learned that you need to use `-DLIBCXX_ENABLE_VENDOR_AVAILABILITY_ANNOTATIONS=ON`.
Bug 1995582 Comment 16 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
This bug's crashes are definitely caused by a bug in LLVM 21. I'm able to trigger them in a local mozilla-central build made using `clang` and `lld` from LLVM 21. This happens with LLVM 21.1.2 as used by Nix, and also with the latest release (LLVM 21.1.4). They don't happen with LLVM 20. Which should be good news to those working on bug 1923255. Source and binary distros for LLVM are available [here](https://github.com/llvm/llvm-project/releases). But there are no macOS binaries for LLVM 21 -- only for LLVM 20. So I had to build them myself, which was a royal pain. [llvm.org's build instructions](https://llvm.org/docs/GettingStarted.html) are incomplete and misleading, so I think it's worthwhile documenting how I built LLVM 21. The basic commands I used were as follows. I first installed Homebrew's `cmake` and `ninja`. ``` cmake -S llvm -B build -G Ninja -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra;lld" -DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi;libunwind;compiler-rt" -DCMAKE_BUILD_TYPE=Release -DLIBCXX_ENABLE_VENDOR_AVAILABILITY_ANNOTATIONS=ON ninja -C build all ninja -C build install ``` LLVM recommends building in two stages -- first using the Apple compiler and linker (`clang` and `ld64`); second using the LLVM compiler and linker (`clang` and `lld`) that you just installed. I did this. For the first stage I used an additional parameter (for example `-DCMAKE_INSTALL_PREFIX=/staging/directory`) to install into a staging directory. For the second, I temporarily put the staging directory at the start of the path: For example `export PATH="/staging/directory/bin:$PATH"`. And I changed the install prefix to point to something more permanent -- for example `-DCMAKE_INSTALL_PREFIX=/usr/local/llvm-project-21.1.4`. For this you need (of course) to use `sudo ninja -C install`. To get `./mach configure` and `./mach build` to use the "wrong" version of LLVM, I changed the `clang` and `lld` shortcuts in `~/.mozbuild/clang/bin`. `./mach configure` fails using LLVM 21. I needed to specify `./mach configure --without-wasm-sandboxed-libraries`. And for both LLVM 21 and 20 I needed to patch trunk code as follows: ``` diff --git a/third_party/zucchini/chromium/components/zucchini/suffix_array_unittest.cc b/third_party/zucchini/chromium/components/zucchini/suffix_array_unittest.cc --- a/third_party/zucchini/chromium/components/zucchini/suffix_array_unittest.cc +++ b/third_party/zucchini/chromium/components/zucchini/suffix_array_unittest.cc @@ -22,7 +22,8 @@ using SLType = InducedSuffixSort::SLType } // namespace -using ustring = std::basic_string<unsigned char>; +//using ustring = std::basic_string<unsigned char>; +using ustring = std::vector<unsigned char>; constexpr uint16_t kNumChar = 256; ``` I found valuable help [here](https://github.com/llvm/llvm-project/issues/155606#issuecomment-3339648510) and [here](https://gist.github.com/hoyhoy/492cf3077239baececb6b838bf620d39). This is where I learned that you need to use `-DLIBCXX_ENABLE_VENDOR_AVAILABILITY_ANNOTATIONS=ON`. I'll be trying to find the bug in LLVM 21. It may take a while.
This bug's crashes are definitely caused by a bug in LLVM 21. I'm able to trigger them in a local mozilla-central build made using `clang` and `lld` from LLVM 21. This happens with LLVM 21.1.2 as used by Nix, and also with the latest release (LLVM 21.1.4). They don't happen with LLVM 20. Which should be good news to those working on bug 1923255. Source and binary distros for LLVM are available [here](https://github.com/llvm/llvm-project/releases). But there are no macOS binaries for LLVM 21 -- only for LLVM 20. So I had to build them myself, which was a royal pain. [llvm.org's build instructions](https://llvm.org/docs/GettingStarted.html) are incomplete and misleading, so I think it's worthwhile documenting how I built LLVM 21. The basic commands I used were as follows. I first installed Homebrew's `cmake` and `ninja`. ``` cmake -S llvm -B build -G Ninja -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra;lld" -DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi;libunwind;compiler-rt" -DCMAKE_BUILD_TYPE=Release -DLIBCXX_ENABLE_VENDOR_AVAILABILITY_ANNOTATIONS=ON ninja -C build all ninja -C build install ``` LLVM recommends building in two stages -- first using the Apple compiler and linker (`clang` and `ld64`); second using the LLVM compiler and linker (`clang` and `lld`) that you just installed. I did this. For the first stage I used an additional parameter (for example `-DCMAKE_INSTALL_PREFIX=/staging/directory`) to install into a staging directory. For the second, I temporarily put the staging directory at the start of the path: For example `export PATH="/staging/directory/bin:$PATH"`. And I changed the install prefix to point to something more permanent -- for example `-DCMAKE_INSTALL_PREFIX=/usr/local/llvm-project-21.1.4`. For this you need (of course) to use `sudo ninja -C install`. To get `./mach configure` and `./mach build` to use the "wrong" version of LLVM, I changed the `clang` and `lld` shortcuts in `~/.mozbuild/clang/bin`. `./mach configure` fails using LLVM 21 and LLVM 20. I needed to specify `./mach configure --without-wasm-sandboxed-libraries`. And for both I needed to patch trunk code as follows: ``` diff --git a/third_party/zucchini/chromium/components/zucchini/suffix_array_unittest.cc b/third_party/zucchini/chromium/components/zucchini/suffix_array_unittest.cc --- a/third_party/zucchini/chromium/components/zucchini/suffix_array_unittest.cc +++ b/third_party/zucchini/chromium/components/zucchini/suffix_array_unittest.cc @@ -22,7 +22,8 @@ using SLType = InducedSuffixSort::SLType } // namespace -using ustring = std::basic_string<unsigned char>; +//using ustring = std::basic_string<unsigned char>; +using ustring = std::vector<unsigned char>; constexpr uint16_t kNumChar = 256; ``` I found valuable help [here](https://github.com/llvm/llvm-project/issues/155606#issuecomment-3339648510) and [here](https://gist.github.com/hoyhoy/492cf3077239baececb6b838bf620d39). This is where I learned that you need to use `-DLIBCXX_ENABLE_VENDOR_AVAILABILITY_ANNOTATIONS=ON`. I'll be trying to find the bug in LLVM 21. It may take a while.
This bug's crashes are definitely caused by a bug in LLVM 21. I'm able to trigger them in a local mozilla-central build made using `clang` and `lld` from LLVM 21. This happens with LLVM 21.1.2 as used by Nix, and also with the latest release (LLVM 21.1.4). They don't happen with LLVM 20. Which should be good news to those working on bug 1923255. Source and binary distros for LLVM are available [here](https://github.com/llvm/llvm-project/releases). But there are no macOS binaries for LLVM 21 -- only for LLVM 20. So I had to build them myself, which was a royal pain. [llvm.org's build instructions](https://llvm.org/docs/GettingStarted.html) are incomplete and misleading, so I think it's worthwhile documenting how I built LLVM 21. The basic commands I used were as follows. I first installed Homebrew's `cmake` and `ninja`. ``` cmake -S llvm -B build -G Ninja -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra;lld" -DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi;libunwind;compiler-rt" -DCMAKE_BUILD_TYPE=Release -DLIBCXX_ENABLE_VENDOR_AVAILABILITY_ANNOTATIONS=ON ninja -C build all ninja -C build install ``` LLVM recommends building in two stages -- first using the Apple compiler and linker (`clang` and `ld64`); second using the LLVM compiler and linker (`clang` and `lld`) that you just installed. I did this. For the first stage I used an additional parameter (for example `-DCMAKE_INSTALL_PREFIX=/staging/directory`) to install into a staging directory. For the second, I temporarily put the staging directory at the start of the path: For example `export PATH="/staging/directory/bin:$PATH"`. And I changed the install prefix to point to something more permanent -- for example `-DCMAKE_INSTALL_PREFIX=/usr/local/llvm-project-21.1.4`. For this you need (of course) to use `sudo ninja -C install`. To get `./mach configure` and `./mach build` to use the "wrong" version of LLVM, I created new shortcuts for `clang` and `lld` in `~/.mozbuild/clang/bin`. `./mach configure` fails using LLVM 21 and LLVM 20. I needed to specify `./mach configure --without-wasm-sandboxed-libraries`. And for both I needed to patch trunk code as follows: ``` diff --git a/third_party/zucchini/chromium/components/zucchini/suffix_array_unittest.cc b/third_party/zucchini/chromium/components/zucchini/suffix_array_unittest.cc --- a/third_party/zucchini/chromium/components/zucchini/suffix_array_unittest.cc +++ b/third_party/zucchini/chromium/components/zucchini/suffix_array_unittest.cc @@ -22,7 +22,8 @@ using SLType = InducedSuffixSort::SLType } // namespace -using ustring = std::basic_string<unsigned char>; +//using ustring = std::basic_string<unsigned char>; +using ustring = std::vector<unsigned char>; constexpr uint16_t kNumChar = 256; ``` I found valuable help [here](https://github.com/llvm/llvm-project/issues/155606#issuecomment-3339648510) and [here](https://gist.github.com/hoyhoy/492cf3077239baececb6b838bf620d39). This is where I learned that you need to use `-DLIBCXX_ENABLE_VENDOR_AVAILABILITY_ANNOTATIONS=ON`. I'll be trying to find the bug in LLVM 21. It may take a while.
This bug's crashes are definitely caused by a bug in LLVM 21. I'm able to trigger them in a local mozilla-central build made using `clang` and `lld` from LLVM 21. This happens with LLVM 21.1.2 as used by Nix, and also with the latest release (LLVM 21.1.4). They don't happen with LLVM 20. Which should be good news to those working on bug 1923255. Source and binary distros for LLVM are available [here](https://github.com/llvm/llvm-project/releases). But there are no macOS binaries for LLVM 21 -- only for LLVM 20. So I had to build them myself, which was a royal pain. [llvm.org's build instructions](https://llvm.org/docs/GettingStarted.html) are incomplete and misleading, so I think it's worthwhile documenting how I built LLVM 21. The basic commands I used were as follows. I first installed Homebrew's `cmake` and `ninja`. ``` cmake -S llvm -B build -G Ninja -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra;lld" -DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi;libunwind;compiler-rt" -DCMAKE_BUILD_TYPE=Release -DLIBCXX_ENABLE_VENDOR_AVAILABILITY_ANNOTATIONS=ON ninja -C build all ninja -C build install ``` LLVM recommends building in two stages -- first using the Apple compiler and linker (`clang` and `ld64`); second using the LLVM compiler and linker (`clang` and `lld`) that you just installed. I did this. For the first stage I used an additional parameter (for example `-DCMAKE_INSTALL_PREFIX=/staging/directory`) to install into a staging directory. For the second, I temporarily put the staging directory at the start of the path: For example `export PATH="/staging/directory/bin:$PATH"`. And I changed the install prefix to point to something more permanent -- for example `-DCMAKE_INSTALL_PREFIX=/usr/local/llvm-project-21.1.4`. For this you need (of course) to use `sudo ninja -C build install`. To get `./mach configure` and `./mach build` to use the "wrong" version of LLVM, I created new shortcuts for `clang` and `lld` in `~/.mozbuild/clang/bin`. `./mach configure` fails using LLVM 21 and LLVM 20. I needed to specify `./mach configure --without-wasm-sandboxed-libraries`. And for both I needed to patch trunk code as follows: ``` diff --git a/third_party/zucchini/chromium/components/zucchini/suffix_array_unittest.cc b/third_party/zucchini/chromium/components/zucchini/suffix_array_unittest.cc --- a/third_party/zucchini/chromium/components/zucchini/suffix_array_unittest.cc +++ b/third_party/zucchini/chromium/components/zucchini/suffix_array_unittest.cc @@ -22,7 +22,8 @@ using SLType = InducedSuffixSort::SLType } // namespace -using ustring = std::basic_string<unsigned char>; +//using ustring = std::basic_string<unsigned char>; +using ustring = std::vector<unsigned char>; constexpr uint16_t kNumChar = 256; ``` I found valuable help [here](https://github.com/llvm/llvm-project/issues/155606#issuecomment-3339648510) and [here](https://gist.github.com/hoyhoy/492cf3077239baececb6b838bf620d39). This is where I learned that you need to use `-DLIBCXX_ENABLE_VENDOR_AVAILABILITY_ANNOTATIONS=ON`. I'll be trying to find the bug in LLVM 21. It may take a while.