Exceptions from std::async cannot be caught on macOS ARM with Clang 18+

[ruoka]

Exceptions from std::async cannot be caught on macOS ARM with Clang 18+

Summary

On macOS ARM with Clang 18+, exceptions thrown from std::async contexts cannot be caught properly. The exception escapes all catch blocks and causes program termination with libc++abi: terminating due to uncaught exception.

Important Finding: This bug is NOT module-specific. It affects both C++ modules and regular C++ code when using std::async.

Environment

• Platform: macOS ARM (Apple Silicon)
• Compiler: Clang 18+ (tested with Clang 21.1.5)
• Standard Library: libc++ (Homebrew LLVM)
• Optimization: All optimization levels (-O0, -O1, -O2, -O3) - bug occurs regardless

Minimal Reproduction

#include <iostream>
#include <stdexcept>
#include <future>

struct custom_exception : public std::runtime_error {
    custom_exception() : std::runtime_error("custom_exception") {}
};

// Key: The std::async call must be in a separate function to trigger the bug
void throw_from_async() {
    auto future = std::async(std::launch::async, []() {
        throw custom_exception{};
    });
    future.get();
}

int main() {
    try {
        throw_from_async();
    }
    catch (const custom_exception& e) {
        std::cout << "SUCCESS: Exception caught: " << e.what() << "\n";
        return 0;
    }
    catch (...) {
        std::cout << "FAILED: Exception not caught\n";
        return 1;
    }
}

Compile:

clang++ -std=c++20 -stdlib=libc++ -O3 \
  -L/opt/homebrew/opt/llvm/lib/c++ -L/opt/homebrew/opt/llvm/lib \
  -Wl,-rpath,/opt/homebrew/opt/llvm/lib/c++ -Wl,-rpath,/opt/homebrew/opt/llvm/lib \
  -lc++ \
  minimal_repro.cpp -o minimal_repro

Or use the provided build script: minimal_repro.sh

Expected: Exception is caught, prints "SUCCESS: Exception caught"

Actual: Program terminates with:

libc++abi: terminating due to uncaught exception of type custom_exception: custom_exception

Root Cause Analysis

Based on investigation, this appears to be related to:

1. LLVM built-in unwinder: The bug is specific to macOS ARM where LLVM's built-in unwinder is enabled by default in Homebrew Clang 18+
2. Exception propagation across threads: The issue manifests specifically with std::async, suggesting problems with exception unwinding across thread boundaries
3. Function boundaries: The bug requires the std::async call to be in a separate function (not inlined into main())

Additional Context

• The bug does not occur on Linux ARM (e.g., Asahi Linux) with the same Clang version
• The bug does not occur with Clang < 18
• The bug affects both module and non-module code
• The bug persists even with explicit RTTI flags (-frtti -fexceptions -fcxx-exceptions)
• The bug occurs at all optimization levels (-O0, -O1, -O2, -O3) - optimization level does not affect the bug

Workaround

No known workaround: The bug occurs at all optimization levels (-O0 through -O3).

The only potential workaround is to avoid using std::async with exceptions on macOS ARM, or to catch exceptions within the async lambda itself before they propagate across thread boundaries.

Related Issues

This may be related to or a duplicate of:

• llvm/llvm-project#92121 - Exception handling issues on macOS ARM

Test Cases

A comprehensive test suite demonstrating the bug is available. The minimal reproduction code is included above, and test files are available as GitHub Gists:

• Minimal reproduction: minimal_repro.cpp (44 lines, also included above)
• Build script: minimal_repro.sh - Automated build and test script
• Full test suite with 11 test cases covering various exception patterns
• Non-module test confirming bug is not module-specific

Steps to Reproduce

1. On macOS ARM, install Homebrew LLVM: brew install llvm
2. Compile the minimal reproduction code above with -O3
3. Run the executable
4. Observe program termination instead of exception being caught

Impact

This bug affects any code using std::async with exception handling on macOS ARM, making it impossible to properly handle exceptions from asynchronous operations. This is a critical issue for production code relying on exception safety in concurrent contexts.

[ruoka]

Standards Compliance Note

This bug violates the C++ standard specification for std::future::get().

According to C++20 Standard Section 33.10.6 [futures.unique_future]:

Effects:

• If the associated state contains a stored exception, throws that exception.
• Otherwise, returns the stored value.

Expected Behavior (Per Standard)

When an exception is thrown in a task executed by std::async:

1. The exception is stored in the future's associated state
2. When future.get() is called, the stored exception is rethrown in the calling thread
3. Normal exception handling applies - the exception can be caught with try-catch blocks

Actual Behavior (Bug)

On macOS ARM with Clang 18+:

• The exception escapes future.get() without being rethrown
• The exception cannot be caught by any catch block
• The program terminates with std::terminate()

This violates the standard's requirement that future.get() must rethrow stored exceptions, making this a standards compliance issue, not just a bug.

Impact

This makes std::async with exception handling non-conforming on macOS ARM, breaking code that relies on standard-compliant exception propagation from asynchronous tasks.

[ruoka]

Suggested labels: c++, libc++, exception-handling, backend:AArch64, platform:Apple.

[llvmbot]

@llvm/issue-subscribers-c-11

Author: Kaius Ruokonen (ruoka)

# Exceptions from std::async cannot be caught on macOS ARM with Clang 18+

Summary

On macOS ARM with Clang 18+, exceptions thrown from std::async contexts cannot be caught properly. The exception escapes all catch blocks and causes program termination with libc++abi: terminating due to uncaught exception.

Important Finding: This bug is NOT module-specific. It affects both C++ modules and regular C++ code when using std::async.

Environment

• Platform: macOS ARM (Apple Silicon)
• Compiler: Clang 18+ (tested with Clang 21.1.5)
• Standard Library: libc++ (Homebrew LLVM)
• Optimization: All optimization levels (-O0, -O1, -O2, -O3) - bug occurs regardless

Minimal Reproduction

#include <iostream>
#include <stdexcept>
#include <future>

struct custom_exception : public std::runtime_error {
    custom_exception() : std::runtime_error("custom_exception") {}
};

// Key: The std::async call must be in a separate function to trigger the bug
void throw_from_async() {
    auto future = std::async(std::launch::async, []() {
        throw custom_exception{};
    });
    future.get();
}

int main() {
    try {
        throw_from_async();
    }
    catch (const custom_exception& e) {
        std::cout << "SUCCESS: Exception caught: " << e.what() << "\n";
        return 0;
    }
    catch (...) {
        std::cout << "FAILED: Exception not caught\n";
        return 1;
    }
}

Compile:

clang++ -std=c++20 -stdlib=libc++ -O3 \
  -L/opt/homebrew/opt/llvm/lib/c++ -L/opt/homebrew/opt/llvm/lib \
  -Wl,-rpath,/opt/homebrew/opt/llvm/lib/c++ -Wl,-rpath,/opt/homebrew/opt/llvm/lib \
  -lc++ \
  minimal_repro.cpp -o minimal_repro

Or use the provided build script: minimal_repro.sh

Expected: Exception is caught, prints "SUCCESS: Exception caught"

Actual: Program terminates with:

libc++abi: terminating due to uncaught exception of type custom_exception: custom_exception

Root Cause Analysis

Based on investigation, this appears to be related to:

1. LLVM built-in unwinder: The bug is specific to macOS ARM where LLVM's built-in unwinder is enabled by default in Homebrew Clang 18+
2. Exception propagation across threads: The issue manifests specifically with std::async, suggesting problems with exception unwinding across thread boundaries
3. Function boundaries: The bug requires the std::async call to be in a separate function (not inlined into main())

Additional Context

• The bug does not occur on Linux ARM (e.g., Asahi Linux) with the same Clang version
• The bug does not occur with Clang < 18
• The bug affects both module and non-module code
• The bug persists even with explicit RTTI flags (-frtti -fexceptions -fcxx-exceptions)
• The bug occurs at all optimization levels (-O0, -O1, -O2, -O3) - optimization level does not affect the bug

Workaround

No known workaround: The bug occurs at all optimization levels (-O0 through -O3).

The only potential workaround is to avoid using std::async with exceptions on macOS ARM, or to catch exceptions within the async lambda itself before they propagate across thread boundaries.

Related Issues

This may be related to or a duplicate of:

• llvm/llvm-project#92121 - Exception handling issues on macOS ARM

Test Cases

A comprehensive test suite demonstrating the bug is available. The minimal reproduction code is included above, and test files are available as GitHub Gists:

• Minimal reproduction: minimal_repro.cpp (44 lines, also included above)
• Build script: minimal_repro.sh - Automated build and test script
• Full test suite with 11 test cases covering various exception patterns
• Non-module test confirming bug is not module-specific

Steps to Reproduce

1. On macOS ARM, install Homebrew LLVM: brew install llvm
2. Compile the minimal reproduction code above with -O3
3. Run the executable
4. Observe program termination instead of exception being caught

Impact

This bug affects any code using std::async with exception handling on macOS ARM, making it impossible to properly handle exceptions from asynchronous operations. This is a critical issue for production code relying on exception safety in concurrent contexts.

[efriedma-quic]

Please don't use AI to write your bug reports. AI can be helpful in some situations, but this isn't really one of them: it's just making your bug report a lot more verbose, and it's hard to tell what bits might be AI-inserted hallucinations.

Have you tried to see if this issue reproduces with Apple clang? There might be some issue with the way Homebrew builds its runtime libraries.

[ruoka]

Have you tried to see if this issue reproduces with Apple clang? There might be some issue with the way Homebrew builds its runtime libraries.

We tested this code using Apple Clang version 16.0.0 on macOS with the ARM64 architecture. We couldn't reproduce the bug in this setup. The tests ran successfully across different optimization levels, including -O0, -O2, and -O3. In every case, the exception was caught as expected.

Environment:
Compiler: Apple Clang 16.0.0 (clang-1600.0.26.6)
Architecture: ARM64 (arm64-apple-darwin23.5.0)
Standard Library: libc++

[EugeneZelenko]

Could you please reproduce problem with LLVM (not Apple) Clang?

[efriedma-quic]

Could you please reproduce problem with LLVM (not Apple) Clang?

The original report is with LLVM from Homebrew, I think. I asked for a test with Apple clang for comparison, since it might indicate the problem is related to how Homebrew is building the libraries.

[ruoka]

We tested with Clang 22.0.0 (a development version from /usr/local/llvm/bin) on macOS with the ARM64 architecture. The bug could not be reproduced in this setup. All tests passed successfully across the tested optimization levels, including -O0, -O2, and -O3. In every case, the exception was caught correctly.