-
Notifications
You must be signed in to change notification settings - Fork 130
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Version 1.11.2
of KSCrash (pinned with Bugsnag 5.7) causes deadlock while reporting user exceptions while sending reports
#143
Comments
Thanks for the report, @anderscarling. I'm in the process of testing against KSCrash 1.15.8 to fix this and some additional issues. There should be a release shortly. |
Nice @kattrali! Please let me know if you want me to test it against my project before you push the pod :) It would be nice if new version of bugsnag-cocoa exposed the new "logAllThreads" parameter of Anyhow, I can confirm that I'm deadlock free using my 1.12.0 branch of bugsnag-cocoa |
Awesome! Already got a patch in for |
@anderscarling I'll need to hold on this to investigate a regression in how KSCrash handles crashes from malloc corruption. It's present in at least 1.13.2 onwards, but I haven't found the start yet, except to say it isn't present in 1.11.2. |
@kattrali Any progress? :) |
5.8 was released earlier that downgrades the version of KSCrash because of the newer versions we were seeing reliability issues with in testing. We are still planning on upgrading KSCrash, but upon seeing the issues with it we rolled back to the last known good version. |
ok, thanks! |
Closing as we have forked an earlier version of KSCrash which does not cause a deadlock. |
Since
KSCrash commit b1d8965 (released in 1.11.0)
added a call tokscrs_getCrashReportPath
tokscrash_i_onCrash
(inKSCrashC.c
) is seems KSCrash will deadlock if an exception is recorded whileg_mutex
(inKSCrashReportStore.c
) is held by another thread.This seems to happen because exception recording suspends all other threads, including the one currently holding the
g_mutex
. This has a high-ish occurrence rate if you call[Bugsnag notify:]
a few times in a row asBugsnagNotifier notify:
ends with doing a[self performSelectorInBackground:@selector(sendPendingReports) withObject:nil];
.It seems this is fixed as a side effect of [
KSCrash commit 4899c8517 (released in 1.12.0)
]((kstenerud/KSCrash@4899c85) as it no longer claimsg_mutex
to get the path for the crash report.I'm currently trying to build bugsnag-cocoa with kscrash 1.12.0 to validate that it actually fixes the issue..
The text was updated successfully, but these errors were encountered: