<p>KSCrash attrape le crash, mais la pile de crash est vide</p>

Je reçois le même problème.

Je rencontre le même problème. Quelqu'un le répare ?

Je rencontre le même problème, mais pourquoi ?

Comment reproduire le problème ?

KSCrash a défini le curseur imageAddress sur 0 dans la fonction kssymbolicator_symbolicate() lors de l'analyse de la table des symboles sans symboles de débogage (Xcode --> paramètres de construction --> style de bande --> symboles de débogage)
Bonne chance ...

Je rencontre le même problème. Quelqu'un le répare ?

Les trois rapports fournis par l'auteur du problème sont liés aux exceptions C++. Quelqu'un a-t-il reçu des plantages non-C++ sans backtrace ?

@ bamx23 # 205 montre pourquoi les plantages C++ ne peuvent pas obtenir la pile plantée. J'ai une question, jusqu'à présent, le problème a-t-il été résolu ? je peux toujours obtenir une pile vide lorsque des exceptions C++ dans des frameworks intégrés ?

Je vais regarder ce problème la semaine prochaine

@ bamx23 j'obtiens beaucoup de pile vide, "diagnosis": "Tentative de déréférencement du pointeur nul."
vide.txt

Si vous rencontrez la pile vide pour l'exception C++, vous pouvez trouver la raison de ce problème. https://github.com/kstenerud/KSCrash/issues/205

Désolé, il aurait été préférable de dire "le mois prochain".
J'ai vérifié le crash de KSCrash sur C++ à partir de mon exemple d'application, mais les threads étaient corrects. Quelqu'un pourrait-il fournir un exemple de code qui reproduit le problème?

@ chzhij5 frère, quelle version de ks utilises-tu ? 1.15.8 ?

Salut! Nous avons étudié le problème et les solutions possibles dans notre équipe. Il existe une:

Pendant le processus d'installation de KSCrashMonitor_CPPException, nous pouvons utiliser un "hack" qui est décrit et implémenté dans https://github.com/facebook/fishhook. Il permet d'accrocher n'importe quel appel de fonction binaire lié dynamiquement. Nous accrochons donc __cxa_throw pour tous les binaires chargés.

Si une bibliothèque a un symbole faible __cxa_throw (comme KSCrash l'a actuellement), nous l'appellerons de la même manière que nous le faisons maintenant. La commande serait comme [fishhooked one] -> [weak one] -> [libc++abi one] .

Le seul problème qui ne peut pas être résolu est que si un binaire contient un symbole fort __cxa_throw , nous ne pouvons pas l'accrocher. Mais je pense qu'il n'y a pas d'option pour faire face à une telle situation.

@kstenerud , qu'en pensez-vous ? Nous avons lu votre message sur stackoverflow et il semble que l'idée ci-dessus puisse le résoudre, au moins partiellement.

Nous pouvons continuer et créer une demande d'extraction où fishhook sera une dépendance de KSCrash (ou de la sous-spécification de KSCrash comme par exemple "KSCrash/Recording/ImprovedCPPExceptionsHandling").

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

Nous pouvons en fait appeler [libc++abi one] partir de [fishhooked one] au cas où si [weak one] ne l'appelle pas, cela répond aux exigences de @kstenerud .

Cela sonne bien, nous ferons un essai la semaine prochaine dans notre application interne.

Ici le PR : #375