MSVC double-free crash not supported?

[stefanstarstable]

Hello,

I've been using sentry-native on PC for a while, and it's been working great. However, I recently noticed that double-free crashes like the below does not generate any crashdump.

auto x = malloc(123);
free(x);
free(x);

The application crashes when running the above code, but no .dmp crashdump is generated, which I believe should happen.

Any idea what could be wrong? Perhaps I'm just missing some compiler flag. I see that there are some limitations regarding fastfails, maybe that is related?

Details about my setup:

• OS: Windows 11
• Language: C++
• Compiler: MSVC, Visual Studio 17.8.7
• Arch: 64bit
• Sentrypad version: 0.6.0

[markushi]

Hi @stefanstarstable, thanks for reaching out! Just to confirm: Are you using the crashpad or breakpad backend in your builds?

On top of that, enabling debugging could shed some light into this:

sentry_options_set_debug(options, true);

[stefanstarstable]

Thanks for the response! We are using crashpad, and we build sentrypad using -DSENTRY_BACKEND=crashpad.

I enabled debug, and got this output before the crash.

[sentry] INFO using database path "C:\xxx\yyy\"
[sentry] DEBUG starting transport
[sentry] DEBUG starting background worker thread
[sentry] DEBUG starting backend
[sentry] DEBUG starting crashpad backend with handler "C:\xxx\crashpad_handler.exe"
[sentry] DEBUG background worker thread started
[sentry] DEBUG using minidump url "https://sentry.io:443/api/1474641/minidump/?sentry_client=sentry.native/0.6.0&sentry_key=zzz"
[sentry] DEBUG registering crashpad WER handler "C:\xxx\crashpad_wer.dll"
[sentry] INFO started crashpad client handler
[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
[sentry] DEBUG sending request using winhttp to "https://sentry.io:443/api/1474641/envelope/":
x-sentry-auth:Sentry sentry_key=zzz, sentry_version=7, sentry_client=sentry.native/0.6.0
content-type:application/x-sentry-envelope
content-length:292

[sentry] DEBUG received response:
HTTP/1.1 200 OK
Date: Wed, 14 Aug 2024 12:40:44 GMT
Via: 1.1 google
Content-Length: 2
Content-Type: application/json
Server: nginx
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
x-envoy-upstream-service-time: 0
strict-transport-security: max-age=31536000; includeSubDomains; preload
Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000

[sentry] DEBUG request handled in 235ms

When the crash happens, my debugger bails out, so I can't see the rest of the log. Is the log written to disk as well?

I forgot to mention it earlier, but this is a Win32 application. Not sure if it makes any difference.

I compared the log output with a log from a console application, and I note I get an additional message:

[sentry] INFO handing control over to crashpad

[supervacuus]

If you run your application inside a debugger, the Sentry handler will not receive the exception (although the debugger can be configured to ignore/pass on exceptions to the application).

Do you see the same behavior when you run your Win32 application outside the debugger? A missing handing control over to crashpad can hint that the debugger got the unhandled exception instead of us, but it could also be other causes.

In this case, though, there is a really good chance it's the former since a double-free will lead to a STATUS_HEAP_CORRUPTION, which should be well handled in crashpad via its vectored exception handler (which it installs just for that exception).

[stefanstarstable]

Yes, I see the same behavior without the debugger attached. Thanks for the additional insights - it sounds like this type of crash should be caught.

I will try to upgrade sentrypad to latest and see if it helps.

[supervacuus]

I will try to upgrade sentrypad to latest and see if it helps.

Oh, yes, thanks for reminding me. I just realized that you wrote that your version is 0.6.0. This feature was added to Crashpad in June of last year, so the first version of the Native SDK that included the handler was 0.6.6.

In 0.6.0, it wouldn't be caught for reasons expressed here.

[stefanstarstable]

We have upgraded and verified that it works as expected now. Thanks for the help!