Sentry_crashpad crashing

I’m having an issue using the crashpad backend in our application. I’ve just updated our integration to the 0.1.4 native c++ sdk and during some tests when throwing exceptions at various places in the codebase I’m seeing the stacktrace in our portal say that we are crashing in sentry_crashpad.dll in HandleAbortSignal in crashpad_win_client.cpp line 188 instead of seeing a trace from where the crash actually took place.

When I don’t throw an exception but deference a nullptr or something else, I don’t have this problem and I see the correct stack trace at the correct location.

Is there something more than initializing the sentry SDK that i have to do to catch exceptions before reporting them to sentry? I was under the impression that crashpad would handle all that for me if i just initialized it?


Hi! Have you found an answer to your question? I just encountered the same problem

Unfortunately, no. No one ever replied, and I wasn’t able to solve it.

0.1.4 is a pretty old version at this point, and I have yet to upgrade our codebase. It would be nice to have someone from sentry weigh in on this though.

0.1.4 is a year old and just after releasing that, we released 0.2.0 completely rewritten in C.

I suggest moving to the latest version.

I’m using 0.2.0. The call stack is a bit different, the top points to line 197 to

0.2.0 came a year ago.

The latest:

When I update our codebase, I’ll post if this issue goes away (fingers crossed) thanks for the response!

I updated to the latest release and the issue is still the same

This is a frequent occurrence for my project. It most often happens following a notification from one of our other libraries, that its ref-counting has become invalid, so I suspect memory corruption may be a factor.

The other interesting point is that our project includes another older C library which uses setjmp/longjmp internally, and the CrashPad HandleAbortSIgnal stack often (90% of the time) references _longjmp_internal as the frame above. I suspect this might be because CrashPad itself uses setjmp/longjmp internally, and something is overwriting its longjmp data.

(This is all a hypothesis)

If anyone has any suggestions on ways to further debug this, my app is producing about 30 crashes a data like this, so should be somewhat easy to try any suggestions and see.

Some reading of the Crashpad code helped, the setjmp/longjmp thing is probably a red-herring. HandleAbortSignal will be triggered by calls abort(), but that includes terminate(). I suspect the crashing line is:

  record.ExceptionAddress = ProgramCounterFromCONTEXT(&context);

Although since context is a stack variable, that might imply the stack is borked.