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 sentry.io 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?
Thanks!
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 crashpad_client_win.cc.
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.