[all-commits] [llvm/llvm-project] ff2438: [lld][MachO] Fix SIGBUS crash in saveOrHardlinkBuf...

[Liza Burakova via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: ff243860d7934d763dea4f3fa345b4bfef6d393c
      https://github.com/llvm/llvm-project/commit/ff243860d7934d763dea4f3fa345b4bfef6d393c
  Author: Liza Burakova <liza at chromium.org>
  Date:   2026-05-26 (Tue, 26 May 2026)

  Changed paths:
    M lld/MachO/LTO.cpp
    A lld/test/MachO/Inputs/large-lto-object.ll
    M lld/test/MachO/lto-object-path.ll

  Log Message:
  -----------
  [lld][MachO] Fix SIGBUS crash in saveOrHardlinkBuffer (#198381)

This change removes a hardlink in saveOrHardlinkBuffer if the
hardlink already exists.

On Mac, -object_path_lto files are hardlinked to the cache when
possible. If the hardlink fails, the saveOrHardlinkBuffer method
falls back to saveBuffer instead.

saveBuffer() opens the file that is being written to as a
raw_fd_ostream object, which truncates a file when opening if the
file already exists.

Most of the time this is not an issue, however, if the hardlink
fails because it actually already exists, AND the hardlink exists
specifically between the -object_path_lto file and the cache file,
then when the file is opened and truncated, we also accidentally
truncate the file we are trying to read from.

This fixes a recurring issue Chromium saw in buildbots that
occassionally hit the above circumstances to cause the crash.
Chromium bug for reference is crbug.com/40060675.

This test adds a new file with a large-ish array (32KB) to ensure
the file is large enough to be mmap'd during the linking process.
This was necessary to reproduce the crash, as smaller files were
not mmap'd. The SIGBUS crash only occurs when the file is mmap'd
then truncated.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications