Skip to content
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

KSCrash catch the crash, but the crash stack is empty #250

Open
chzhij5 opened this issue Jul 27, 2017 · 17 comments
Open

KSCrash catch the crash, but the crash stack is empty #250

chzhij5 opened this issue Jul 27, 2017 · 17 comments

Comments

@chzhij5
Copy link

chzhij5 commented Jul 27, 2017

I get some crash report from our user, but I found that some of the crash stack is empty.
2017-07-27 3 00 07

These are some of the raw json crash report.
1.txt
2.txt
3.txt

@JinchengKim
Copy link

I get the same issue.

@FadeFei
Copy link

FadeFei commented Oct 9, 2017

I meet the same problem. Anyone fix it?

@paulmanwang
Copy link

I meet the same problem, but why?

@tuyuwang
Copy link

tuyuwang commented Jan 7, 2019

How to reproduce the problem?

@huakucha
Copy link

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 ...

@guzuqing
Copy link

guzuqing commented Mar 5, 2019

I meet the same problem. Anyone fix it?

@bamx23
Copy link
Collaborator

bamx23 commented Mar 7, 2019

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

@guzuqing
Copy link

guzuqing commented Mar 7, 2019

@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?

@bamx23
Copy link
Collaborator

bamx23 commented Mar 7, 2019

I'll take a look at this problem next week

@guzuqing
Copy link

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

@chzhij5
Copy link
Author

chzhij5 commented Mar 27, 2019

If meet the empty stack for C++ exception, can find the reason on this issue. #205

@bamx23
Copy link
Collaborator

bamx23 commented Apr 10, 2019

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?

@guzuqing
Copy link

@chzhij5 老哥,你们用的是哪个版本的ks?1.15.8?

@bamx23
Copy link
Collaborator

bamx23 commented Aug 28, 2019

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`).

@GLinnik21
Copy link
Contributor

GLinnik21 commented Aug 28, 2019

[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.

@ZhiyuWong
Copy link
Collaborator

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

@bamx23
Copy link
Collaborator

bamx23 commented May 30, 2020

Here the PR: #375

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants