<p>KSCrash atrapa el bloqueo, pero la pila de bloqueo está vacía</p>

Tengo el mismo problema.

Me encuentro con el mismo problema. ¿Alguien lo arregla?

Me encuentro con el mismo problema, pero ¿por qué?

¿Cómo reproducir el problema?

KSCrash estableció la dirección de imagen del cursor en 0 en la función kssymbolicator_symbolicate() al analizar la tabla de símbolos sin símbolos de depuración (Xcode --> configuración de compilación --> Estilo de tira --> Símbolos de depuración)
Buena suerte ...

Me encuentro con el mismo problema. ¿Alguien lo arregla?

Los tres informes que proporcionó el autor del problema están relacionados con las excepciones de C++. ¿Alguien ha recibido fallas que no sean de C++ sin seguimiento?

@ bamx23 # 205 muestra por qué los bloqueos de C ++ no pueden obtener la pila bloqueada. tengo una pregunta, hasta ahora se soluciono el problema? ¿Todavía puedo obtener una pila vacía cuando las excepciones de C ++ en marcos integrados?

Voy a echar un vistazo a este problema la semana que viene

@ bamx23 obtengo una gran cantidad de pilas bloqueadas vacías, "diagnóstico": "Intenté eliminar la referencia del puntero nulo".
vacío.txt

Si cumple con la pila vacía para la excepción de C++, puede encontrar el motivo de este problema. https://github.com/kstenerud/KSCrash/issues/205

Lo siento, hubiera sido mejor decir "el próximo mes".
Revisé KSCrash en el bloqueo de C ++ desde mi aplicación de muestra, pero los hilos estaban bien. ¿Alguien podría proporcionar un código de ejemplo que reproduzca el problema?

@chzhij5 hermano, ¿qué versión de ks estás usando? 1.15.8?

¡Hola! Investigamos el problema y las posibles soluciones en nuestro equipo. Hay uno:

Durante el proceso de instalación de KSCrashMonitor_CPPException, podemos usar un "truco" que se describe e implementa en https://github.com/facebook/fishhook. Permite enganchar cualquier llamada de función binaria enlazada dinámicamente. Entonces conectamos __cxa_throw para todos los binarios cargados.

Si alguna biblioteca tiene un símbolo débil __cxa_throw (como lo tiene KSCrash actualmente), lo llamaremos de la misma manera que lo hacemos ahora. El pedido sería como [fishhooked one] -> [weak one] -> [libc++abi one] .

El único problema que no se puede resolver es que si algún binario tiene un fuerte símbolo __cxa_throw , no podemos conectarlo. Pero creo que no hay opción para hacer frente a una situación así.

@kstenerud , ¿qué opinas? Hemos leído su publicación en stackoverflow y parece que la idea anterior puede resolverlo, al menos parcialmente.

Podemos continuar y crear una solicitud de extracción donde el anzuelo será una dependencia de KSCrash (o subespecificación de KSCrash como, por ejemplo, 'KSCrash/Recording/ImprovedCPPExceptionsHandling`).

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

De hecho, podemos llamar a [libc++abi one] desde [fishhooked one] en caso de que [weak one] no lo llame, eso satisface los requisitos de @kstenerud .

Eso suena bien, lo intentaremos la próxima semana en nuestra aplicación interna.

Aquí el PR: #375