Tengo un proyecto Xcode de escritorio OSX queincluye otro proyecto Xcode (un marco) como dependencia. Cuando construyo un archivo de la aplicación, genera dos paquetes dSYM: uno para la aplicación y otro para el marco.
Cuando simbolizo bloqueos recibidos de la aplicación,los símbolos del paquete de la aplicación se muestran correctamente (con nombres de archivos y números de línea). Sin embargo, los símbolos del marco no se simbolizan en absoluto, solo muestran el nombre del marco y la dirección de memoria. ¿Hay alguna forma de simbolizar las partes del seguimiento de la pila que involucra el código del marco?
Mirando el archivo desde el que generé el paquete .app, el UUID del dSYM del framework no coincide con el que se copia en la carpeta "Frameworks" en el .app:
El marco HCCommon dentro del paquete .app en el archivo comprimido:
/path/to/HipChat.xcarchive $ dwarfdump --uuid Products/Applications/HipChat.app/Contents/Frameworks/HCCommon.framework/HCCommon
UUID: 84891A9C-19DB-3E16-BE7E-9D4056FFFB97 (x86_64) Products/Applications/HipChat.app/Contents/Frameworks/HCCommon.framework/HCCommon
vs el dSYM del marco HCCommon (en el directorio dSYMs en el archivo de almacenamiento):
/path/to/HipChat.xcarchive $ dwarfdump --uuid dSYMs/HCCommon.framework.dSYM/Contents/Resources/DWARF/HCCommon
UUID: 767F2D97-9E0B-3C4D-8337-FDF5A9CA2D81 (x86_64) dSYMs/HCCommon.framework.dSYM/Contents/Resources/DWARF/HCCommon
Respuestas
4 para la respuesta № 1No estoy seguro de por qué su compilación está dando como resultado inconsistentes dSYM UUID. Cuando hacemos este tipo de compilaciones (después de haber verificado algunas en este momento), tenemos UUID consistentes.
Sin embargo, en respuesta a su pregunta sobre cómopuede simbolizar los informes de fallos que ya ha recibido dados los .dSYM que ya tiene (suponiendo por el momento que, aunque los UUID coinciden, se refieren a un código idéntico y, por lo tanto, funcionarían).
He encontrado que lo siguiente funciona bien si tiene que forzar el dsym específico:
atos -arch x86_64 -o <path_to_dsym_within_package> -l <offset_of_framework>
Ciertamente no es tan bonito y, en general, ejecuto las direcciones individuales a través de atos manualmente, pero el resultado es una combinación de rutina / línea válida (suponiendo que coincida con las versiones correctas, etc.)
los <path_to_dsym_within_package> se refiere a foo.framework.dSYM/Contents/Resources/DWARF/foo seguido de su nombre binario, donde foo Es el nombre del marco. Para nosotros, esto también funciona para cualquier tipo de complemento.
los <offset_of_framework> es de la columna de desplazamiento en el registro de bloqueo, donde:
0 libsystem_kernel.dylib 0x7fff8e785ce2 0x7fff8e76f000 + 93410
1 libsystem_c.dylib 0x7fff871afa7a 0x7fff8716e000 + 268922
2 CTUtils 0x104e26c62 0x104e17000 + 64610
En este caso, el primer número hexadecimal es la dirección, el segundo número hexadecimal es el desplazamiento inicial para el marco particular y el valor + es el desplazamiento decimal dentro del marco.
Necesitará el segundo número (desplazamiento hexadecimal) para la línea de comando anterior y el primer número para encontrar la rutina específica / número de línea.
En el peor de los casos, siempre se usa dwarfdump directamente, usando:
dwarfdump <path_to_dSYM> --arch x86_64 --lookup <offset>
<path_to_dSYM> es la ruta a la carpeta de nivel superior ".dSYM" (a diferencia de atos comando anterior), y <offset> es el desplazamiento dentro del módulo, que no es tan conveniente como atos.
PD atos debe instalarse en /usr/bin/atos si tienes instaladas las herramientas de desarrollo.
1 para la respuesta № 2
Encontré este problema también. Después de un poco de investigación, resultó que Xcode estaba copiando depurar framework se integra en versiones de lanzamiento, pero, aparentemente, crea dSYM a partir de los binarios de lanzamiento correctos.
Esto fue a pesar de usar Xcode para agregar el marcodependencias del espacio de trabajo. Finalmente descubrí por qué: los marcos se incluyeron en el proyecto con su ubicación "Relativa al grupo" por alguna razón. Después de asegurarme de que todo era "Relativo al producto de construcción", resolvió el problema para mí. No digo que sea la única causa posible, pero vale la pena verificar dos veces todas las rutas en el registro de compilación, porque Xcode no advertirá sobre nada en este caso.
