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
Incorrect stack traces for C++ exceptions in embedded frameworks #205
Comments
Any luck with this? I'm trying to integrate KSCrash in my app, but stuck because of embedded framework. |
No luck, and I don't believe it is possible, at least not in our use case. This is my understanding of the situation: The way KSCrash records the stack trace is by creating its own implementation of __cxa_throw, which allow access to the stack before it is unwound by libc++. This works as long as KSCrash is statically linked with the C++ code, since the linker will find and use __cxa_throw form KSCrash instead of the implementation in libc++. But in the case of an embedded framework that links to libc++, the __cxa_throw implementation from libc++ will be used, since the framework doesn't know about the code in KSCrash. Maybe there is a work-around if you have control over the embedded framework, but this won't work in our use-case. Please let me know if you figure out a solution. |
I have control over the embedded framework. But not sure how to fix it. |
Does this mean that KSCrash should ideally be built as a static library and linked into the application, to at least catch C++ exceptions thrown in the application code? But that would still leave any exceptions thrown in any dynamic library uncaught by KSCrash if I understand your bug report correctly @pdrtrifork ? If we control the embedded dynamic libs, could we link in a static lib to each of them with just that __cxa_throw stub, which would just defer to a shared KSCrash handler? |
Hah, so in investigating this I ended up here http://stackoverflow.com/questions/36846628/conditionally-overriding-cxa-throw, which was opened by our very own @kstenerud 😄 Anyways, PR #219 should at least prevent crashing during crash reporting. |
@kstenerud I think this issue should be renamed to something like "Missing stack traces for C++ exceptions thrown from images not statically linked with KSCrash". As far as I can tell, the
The latter would affect clients such as |
After further investigation it seems my previous comment was incorrect:
In the case of KSCrash being linked into the main application as a static library:
Any exceptions thrown from In the case of KSCrash being linked into the main application as a dynamic library:
Any exceptions thrown from
If This leads me to belive that the Like for the first usecase, any exceptions thrown from This issue could potentially be fixed with some low level runtime patching of loaded images with undefined references to |
I'm trying to check crash in a framework in my app. When I try to get the crash log I see that stack trace is not showing the actual crash, instead KSCrash is crashing. Is this the same issue? Thread 0 Crashed: |
@torarnv Hi, could you share your successful mach-o-hook demo with us? I ran into EXC_BAD_ACCESS when I try to |
try this... good luck |
It looks like the __cxa_throw function in KSCrashMonitor_CPPException.c is not getting called when a C++ exception is thrown in an embedded framework, e.g. CrashLib in the Crash-Tester app.
I haven't been able to come up with a solution to this. To me it looks like any embedded library will always use __cxa_throw from libc++, and not the implementation in KSCrash.
Additionally: When an unhandled C++ exception is thrown in an embedded framework, KSCrash will crash during reporting, since stackCursor->advanceCursor will equal NULL in KSCrashReport.c:writeBacktrace().
Edit: Added information KSCrash crashing during reporting.
The text was updated successfully, but these errors were encountered: