KSCrash catch the crash, but the crash stack is empty

I get the same issue.

I meet the same problem. Anyone fix it?

I meet the same problem, but why?

How to reproduce the problem？

KSCrash set the cursor imageAddress to 0 in function kssymbolicator_symbolicate() when parsing the symbol table without Debugging Symbols(Xcode --> build settings --> Strip Style -- >Debugging Symbols)
Good Luck ...

I meet the same problem. Anyone fix it?

All three reports issue author provided are related to C++ exceptions. Has anyone received non-C++-crashes without backtrace?

@bamx23 #205 shows why C++ crashes can't get the crashed stack. i have a question , Until now, does the issue has been solved ? i can still get a empty stack when C++ exceptions in embedded frameworks?

I'll take a look at this problem next week

@bamx23 i get a lot empty crashed stack, "diagnosis": "Attempted to dereference null pointer."
empty.txt

If meet the empty stack for C++ exception, can find the reason on this issue. https://github.com/kstenerud/KSCrash/issues/205

Sorry, it would have been better to say "next month".
I've checked KSCrash on C++ crash from my sample app, but threads were ok. Could someone provide an example code that reproduces the problem?

@chzhij5 老哥，你们用的是哪个版本的ks？1.15.8？

Hi! We investigated the problem and possible solutions in our team. There is one:

During installation process of KSCrashMonitor_CPPException we can use a "hack" that is described and implemented in https://github.com/facebook/fishhook. It allows hooking any call of dynamically linked binary's function. So we hook __cxa_throw for all loaded binaries.

If any library has a weak symbol __cxa_throw (like KSCrash has currently) we will call it the same way we do it now. The order would be like [fishhooked one] -> [weak one] -> [libc++abi one].

The only problem that can't be solved is if some binary has strong __cxa_throw symbol in it we can't hook it. But I think that there is no option to deal with such a situation.

@kstenerud, what do you think? We've read your post at stackoverflow, and it seems that the idea above may solve it, at least partially.

We can go ahead and create a pull-request where fishhook will be a dependancy of KSCrash(or KSCrash subspec like i.e. 'KSCrash/Recording/ImprovedCPPExceptionsHandling`).

[fishhooked one] -> [weak one] -> [libc++abi one].

We actually can call [libc++abi one] from [fishhooked one] in case if [weak one] does not call it, that satisfies @kstenerud's requirements.

That sounds good, we will have a try next week in our in-house app.

Here the PR: #375