[MacOS] Application hangs on second call to sentry_handle_exception

[EvgenPervenenko]

Description
When calling sentry_handle_exception multiple times in succession, the application hangs after the second call. Below is a code example that demonstrates the issue

When does the problem happen

• During build
• During run-time
• When capturing a hard crash

Environment

• OS: macOS 15.2 m1
• Compiler: Ninja arm64
• CMake version and config: [e.g. 3.28.1, SENTRY_BACKEND=breakpad]
• sentry-native 0.7.15(static)

Steps To Reproduce
Minimal code snippet:

#include <sentry.h>
#include <iostream>

sentry_value_t onCrash(const sentry_ucontext_t* /*uctx*/, sentry_value_t event, void* /*closure*/)
{
    std::cout << "onCrash()" << std::endl;
    return event;
}

int main(int argc, char *argv[])
{
    sentry_options_t *options = sentry_options_new();
    sentry_options_set_dsn(options, "https://dsn");
    sentry_options_set_release(options, "project@version");
    sentry_options_set_sample_rate(options, 1.0);
    sentry_options_set_max_breadcrumbs(options, 50);
    sentry_options_set_on_crash(options, ::onCrash, nullptr);
    sentry_options_set_environment(options, "integration");
    sentry_options_set_debug(options, 1);
    sentry_init(options);

    {
        std::cout << "Request 1 start" << std::endl;
        sentry_ucontext_t context = {};
        context.signum = SIGSEGV;
        sentry_handle_exception(&context);
        std::cout << "Request 1 end" << std::endl;
    }

    {
        std::cout << "Request 2 start" << std::endl;
        sentry_ucontext_t context = {};
        context.signum = SIGSEGV;
        sentry_handle_exception(&context);
        std::cout << "Request 2 end" << std::endl;
    }

    {
        std::cout << "Request 3 start" << std::endl;
        sentry_ucontext_t context = {};
        context.signum = SIGSEGV;
        sentry_handle_exception(&context);
        std::cout << "Request 3 end" << std::endl;
    }

    return 0;
}

Log output

[sentry] INFO using database path ".sentry-native"
[sentry] DEBUG starting transport
[sentry] DEBUG starting background worker thread
[sentry] DEBUG starting backend
[sentry] DEBUG background worker thread started
[sentry] DEBUG processing and pruning old runs
[sentry] DEBUG sending envelope
[sentry] DEBUG submitting task to background worker thread
[sentry] DEBUG executing task on worker thread
Request 1 start
[sentry] INFO handling exception
[sentry] INFO entering breakpad minidump callback
[sentry] DEBUG invoking `on_crash` hook
onCrash()
[sentry] DEBUG merging scope into event
[sentry] DEBUG adding attachments to envelope
[sentry] DEBUG sending envelope
[sentry] INFO writing envelope to file failed
[sentry] DEBUG dumped 1 in-flight envelopes to disk
[sentry] INFO crash has been captured
Request 1 end
Request 2 start
[sentry] INFO handling exception
* Host ****.ingest.de.sentry.io:443 was resolved.
* IPv6: (none)
* IPv4: 34.120.62.213
*   Trying 34.120.62.213:443...
* ALPN: curl offers http/1.1
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: ingest.de.sentry.io
* Server certificate: DigiCert Global G2 TLS RSA SHA256 2020 CA1
* Server certificate: DigiCert Global Root G2
* Connected to ****.ingest.de.sentry.io (34.120.62.213) port 443
* using HTTP/1.x
> POST /api/****/envelope/ HTTP/1.1
Host: ****.ingest.de.sentry.io
User-Agent: sentry.native/0.7.15
Accept: */*
x-sentry-auth:Sentry sentry_key=****, sentry_version=7, sentry_client=sentry.native/0.7.15
content-type:application/x-sentry-envelope
content-length:571714

* upload completely sent off: 571714 bytes
< HTTP/1.1 200 OK
< server: nginx
< date: Tue, 17 Dec 2024 18:05:58 GMT
< content-type: application/json
< vary: origin, access-control-request-method, access-control-request-headers
< access-control-allow-origin: *
< access-control-expose-headers: x-sentry-error,x-sentry-rate-limits,retry-after
< cross-origin-resource-policy: cross-origin
< strict-transport-security: max-age=31536000; includeSubDomains; preload
< via: 1.1 google
< Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
< Transfer-Encoding: chunked
< 
{"id":"54e2da8a044945c4e79ab0c71b5cc3d4"}* Connection #0 to host ****.ingest.de.sentry.io left intact

Hung up stacktrace:

1 __psynch_mutexwait                                                                  (arm64e) /usr/lib/system/libsystem_kernel.dylib  0x191f21bbc 
2 _pthread_mutex_firstfit_lock_wait                                           (arm64e) /usr/lib/system/libsystem_pthread.dylib 0x191f5d3f8 
3 _pthread_mutex_firstfit_lock_slow                                          (arm64e) /usr/lib/system/libsystem_pthread.dylib 0x191f5adbc 
4 google_breakpad::ExceptionHandler::WriteMinidump(bool) (arm64) TestApp                                  0x102563b74 
5 sentry_handle_exception                                                           (arm64) TestApp                                  0x1024c8fb0 
6 main                                        main.cpp                                      34 0x100691258 
7 start                                                                                              (arm64e) /usr/lib/dyld                           0x191be0274 

[supervacuus]

sentry_handle_exception() is a terminal end to an application. It isn't meant as a generic minidump generator. There are no guarantees for a second call to sentry_handle_exception() or that it even returns.

Breakpad explicitly holds the lock if the mach_msg to the handler was successful because that means a terminal exception was handled (i.e., program termination). In some configurations, the breakpad handler even exits the application, whereas you can still do minor steps here since you manually trigger the dump.

What are you trying to achieve?

[EvgenPervenenko]

@supervacuus hi, thanks for clarification, I am going to get minidumps when one of my working threads is freeze and send it to sentry, for windows it works fine, but for macos I have this issue