Esta es una gran pregunta, y una oportunidad para corregir algunos conceptos erróneos comunes.
Hay varias cosas en juego aquí:
- Cuando ocurre un crash, las cosas que se recogen son:
- los estados de los registros de la CPU, incluyendo el contador de programa
- la pila de estado de los hilos, que se simboliza, si es posible
- el mapa de direcciones de lo que se ha colgado, que se simboliza, si es posible
- la información sobre el hilo que estaba activo en el momento del fallo
- Las cosas que NO se recogen son:
- Cualquier información de identificación sobre la máquina en la que se ha producido el fallo, o el propietario de las máquinas: tal y como señaló Niels: Apple no tiene forma de saber de quién procede el informe de fallo, y mucho menos de ponerse en contacto con usted personalmente para resolver el problema. La única manera de que Apple disponga de esta información es si usted mismo recopila explícitamente la información sobre el fallo en un informe de error y lo envía manualmente, junto con la información de contacto y la solicitud de que se pongan en contacto con usted.
- Los datos con los que operaba el software en el momento del fallo; esto significa que los informes de fallos no sirven para encontrar errores en el software, como por ejemplo que Microsoft Word se bloquee porque se le ha introducido un archivo .DOC corrupto, ya que los informes no contendrán el archivo .DOC defectuoso.
- Información simbólica, si se suprime; si ese es el caso, el informe sólo contendrá números, y éstos normalmente serán inútiles para encontrar el fallo.
- La mayoría de los fallos se producen en software de terceros, lo que significa que Apple no puede hacer nada al respecto. Si el desarrollador del software es un desarrollador registrado de Apple en buen estado, y se mantiene en contacto regular con Apple, Apple, probablemente, remitirá los informes de accidente al desarrollador. Pero, de nuevo, dado que los informes no incluyen información identificable, no esperes que el desarrollador pueda ponerse en contacto contigo, aunque solucione el problema. Póngase en contacto con el desarrollador directamente, para que se le notifique una solución, si la hay.
- Apple utiliza ASLR (Address Space Layout Randomization). Se trata de una técnica que dificulta la tarea de un atacante, ya que no sabe dónde se encuentra en la memoria el código para hacer lo que quiere. Así que si, por ejemplo, provocan con éxito un desbordamiento de búfer en su navegador, no pueden utilizarlo para ejecutar código arbitrario, porque no saben dónde están las funciones que quieren llamar en el espacio de direcciones. Piense en ello como si se tratara de reorganizar los muebles de una persona ciega cada vez que sale de su casa: hace la vida de los atacantes miserable. Pero esta es también la razón por la que, sin simbolización, los informes de crash son en su mayoría inútiles.
Típicamente hablando, como alguien que ha tratado con estas cosas dentro de Apple: los informes de crash se mueven muy muy lentamente.
Los informes de crash llegan primero a la parte de Relaciones con los Desarrolladores de Apple; esto es porque la mayoría de los crash son programas de terceros, no programas de Apple.
Cuando los fallos ocurren, se registran, pero hasta que alcanzan un umbral de recurrencia, incluso si son productos de Apple, simplemente se registran y se cuentan.
Una vez que alcanzan el umbral, si se trata de un producto de terceros, se contacta con el desarrollador -si puede ser- y se le entregan los informes. Si se trata de un producto de Apple, va a la división de Apple a cargo del producto.
Para los productos de Apple, la división que recibe el informe puede o no ser capaz de hacer algo al respecto.
Si se trata de un fallo de «datos erróneos» … un error que se desencadena al alimentar un programa con datos erróneos, y que nunca ocurre en la operación ordinaria … aparte de la inspección del código fuente de la zona del accidente, y tal vez algunas medidas profilácticas, donde el código se niega a operar en absoluto cuando se dan datos erróneos, probablemente no se hará nada al respecto. La inspección del código fuente es difícil, y encontrar ese tipo de error es difícil si usted tiene la inclinación correcta de la mente, y la mayoría de los desarrolladores de aplicaciones no tienen esa inclinación.
Ellos no son hackers de sombrero blanco / sombrero gris / sombrero negro, y su mente por lo general no va en la dirección de cómo elaborar los datos para hacer que el código se comporte mal intencionalmente. En general, la mayoría de los programadores de computadoras caen en esta categoría, de no ser capaces de pensar en el problema; esto es un error de omisión, y en general: simplemente no se espera.
Si tienen suerte, es un problema de seguridad, y una persona de seguridad se sentará con ellos, y será capaz de ayudarles con esto. O tienen un ingeniero senior con el giro correcto en su forma de pensar que se sentará y lo mirará.
De cualquier manera, encontrar ese tipo de error es costoso.
Si se trata de un fallo de código malo, por otro lado, es probable que se encuentre, sobre todo si hay más que suficientes ejemplos para seguir.
Una de las razones por las que hay un umbral es para asegurar que hay suficientes ejemplos, y si los hay, hace que el problema sea fácil de encontrar, porque obviamente hay algo que no se ha tenido en cuenta.
Con las pilas simbólicas y la identificación de los registros, incluyendo el contador de programa, y la identificación de la disposición de las direcciones de la aplicación, puedes cargar la aplicación en un depurador, forzando la disposición de su espacio de direcciones para que coincida con la disposición del ASLR, y eso te dará la línea de código fuente en la que se produjo el fallo.
Los registros en ese momento le dirán cuáles son los valores de las variables, al menos para las cosas que están optimizadas en los registros – que es la mayoría de las cosas – y el contador de programa le dará la instrucción de máquina precisa.
Sin embargo… una gran cantidad de errores se producen como resultado de lo que se llama fallos en cascada. Un fallo en cascada ocurre cuando algo va mal, pero no se detecta inmediatamente, normalmente por una comprobación de errores insuficiente en el código.
Un fallo en cascada muy común es cuando falla una asignación de memoria, se asigna un puntero a la asignación fallida (haciéndolo NULL), y entonces, potencialmente mucho, mucho tiempo después del hecho, el puntero es desreferenciado como si contuviera memoria detrás de él, y se produce un fallo (en Mac OS X, la página 0 se mapea como inaccesible, para evitar que alguien asigne una página allí sin mucho trabajo, por lo que esto se muestra como un SIGBUS, en lugar de un SIGSEGV; el código de excepción es uno de los códigos de estado del procesador que se captura como parte del informe de fallo, ya que el registro de estado es uno de los registros que se vuelca).
En otras palabras, puede costar mucho trabajo, pero una vez que se sabe que está sucediendo, se puede prevenir, o al menos se puede capturar el error y hacer aparecer un diálogo en lugar de bloquearse.
Solía trabajar en el propio kernel de Mac OS X (este es también el kernel de iOS). Estos cuelgues se consideran de gran gravedad, pero… curiosamente, pasan por las mismas reglas de umbral antes de ser enviados a un ingeniero para su análisis.
Típicamente, sin un informe externo, estas son las cosas en las que trabajas cuando no hay nada más que’ sea más urgente trabajar.
Suelen ser muy difíciles de encontrar.
Y son realmente gratificantes, cuando las encuentras, aunque a la dirección generalmente no le importa, ya que no impactan en los horarios, a no ser que tengas a alguien de fuera yendo por los canales de soporte quejándose de ellas.
En otras palabras: tienden a ser de baja prioridad en comparación con, por ejemplo, las Listas de Control de Acceso que no impiden el acceso a algo cuando deberían, o que impiden el acceso a algo cuando no deberían, etc.
La línea de fondo, sin embargo: si es lo suficientemente malo para usted que hace que las cosas sean inutilizables, y necesita ayuda con ello:
Vaya a través de los canales de soporte de los desarrolladores o de los usuarios, en lugar de confiar en que los informes de fallos mágicamente arreglen las cosas para usted.
Las cosas pueden ser «arregladas mágicamente» con el tiempo, pero usted nunca va a saber de ellas, e incluso si están en una nota de la versión, usted no va a saber que algo como «Arreglar el error en el manejo de los descriptores de hardware cuando se indica que el canal Alfa está presente, pero no tiene bits establecidos en la primera columna» es lo mismo que «Cuando hago clic aquí, el programa se bloquea».