C'est une excellente question, et une occasion de corriger certaines idées fausses courantes.
Il y a plusieurs choses en jeu ici :
- Lorsqu'un crash se produit, les éléments qui sont collectés sont :
- les états des registres du CPU, y compris le compteur de programme
- la pile d'état du thread, qui est symbolisée, si possible
- la carte d'adresse de ce qui a crashé, qui est symbolisée, si possible
- des informations quant au thread qui était actif au moment du crash
- Les choses qui ne sont PAS collectées sont :
- Toute information d'identification sur la machine sur laquelle le crash s'est produit, ou le propriétaire des machines : Comme Niels l'a noté : Apple n'a aucun moyen de savoir de qui provient le rapport de crash, et encore moins de vous contacter personnellement pour résoudre le problème. La seule façon pour Apple d'avoir ces informations est de rassembler explicitement les informations de crash vous-même dans un rapport de bug, et de le soumettre manuellement, avec les informations de contact, et une demande qu'ils vous recontactent.
- Les données qui étaient exploitées par le logiciel au moment du crash ; cela signifie que les rapports de crash ne sont pas bons pour trouver des bugs dans les logiciels, comme Microsoft Word qui se plante parce que vous lui avez fourni un fichier .DOC corrompu, puisque les rapports ne contiendront pas le mauvais fichier .DOC.
- Les informations symboliques, si elles'sont supprimées ; si c'est le cas, le rapport ne contiendra que des chiffres, et ceux-ci seront généralement inutiles pour trouver le bug.
- La plupart des crashs se produisent dans des logiciels tiers, ce qui signifie qu'Apple ne peut rien y faire. Si le développeur du logiciel est un développeur Apple enregistré et en règle, et qu'il reste en contact régulier avec Apple, Apple, transmettra probablement les rapports de crash au développeur. Mais là encore, comme les rapports ne contiennent pas d'informations permettant de vous identifier, ne vous attendez pas à ce que le développeur soit en mesure de vous contacter, même s'il résout le problème. Contactez plutôt le développeur directement, afin d'être informé d'une éventuelle correction.
- Apple utilise l'ASLR (Address Space Layout Randomization). Il s'agit d'une technique qui rend la tâche plus difficile pour un attaquant, puisqu'il ne sait pas où se trouve le code permettant de faire ce qu'il veut dans la mémoire. Ainsi, s'il réussit, par exemple, à provoquer un dépassement de tampon dans votre navigateur, il ne peut pas l'utiliser pour exécuter un code arbitraire, car il ne sait pas où se trouvent les fonctions qu'il veut appeler dans l'espace d'adressage. Pensez-y comme si vous réorganisiez les meubles dans la maison d'un aveugle chaque fois qu'il sort de chez lui : cela rend la vie des attaquants misérable. Mais c'est aussi pourquoi, sans symbolication, les rapports de crash sont pour la plupart inutiles.
Typiquement parlant, en tant que personne ayant traité ces choses à l'intérieur d'Apple : les rapports de crash sont déplacés très très lentement.
Les rapports de crash arrivent d'abord à la partie Relations avec les développeurs d'Apple ; c'est parce que la plupart des crashs sont des programmes tiers, pas des programmes Apple.
Lorsque les crashs se produisent, ils sont enregistrés, mais jusqu'à ce qu'ils atteignent un seuil de récurrence, même s'il s'agit de produits Apple, ils sont simplement enregistrés, et comptés.
Une fois qu'ils atteignent le seuil, si c'est un produit tiers, le développeur est contacté -- s'il peut l'être -- et on lui remet les rapports. Si c'est un produit Apple, il va à la division Apple en charge du produit.
Pour les produits Apple, la division qui reçoit le rapport peut ou non être en mesure de faire quelque chose.
S'il's'agit d'un crash de "mauvaises données" .... un bogue qui se déclenche en alimentant un programme en mauvaises données, et qui ne se produit jamais en fonctionnement ordinaire ... à part l'inspection du code source de la zone de crash, et peut-être quelques mesures prophylactiques, où le code refuse de fonctionner du tout lorsqu'il reçoit de mauvaises données, probablement rien ne sera fait à ce sujet. L'inspection du code source est difficile, et trouver ce genre de bogue est difficile si vous avez la bonne tournure d'esprit, et la plupart des développeurs d'applications n'ont pas cette tournure d'esprit.
Ils ne sont pas des hackers white hat/grey hat/black hat, et leur esprit ne va généralement pas dans le sens de comment fabriquer des données pour faire intentionnellement mal se comporter le code. En général, la plupart des programmeurs informatiques tombent dans cette catégorie, de ne même pas être capable de penser au problème ; c'est une erreur d'omission, et généralement : tout simplement pas prévu.
S'ils sont chanceux, c'est un problème de sécurité, et une personne de sécurité s'assiéra avec eux, et sera en mesure de les aider avec cela. Ou bien ils ont un ingénieur senior avec la bonne torsion sur leur façon de penser qui va s'asseoir et regarder cela.
Dans les deux cas, trouver ce type d'erreur est coûteux.
Si c'est un mauvais plantage de code, d'autre part, il sera probablement trouvé, en particulier s'il y a plus que suffisamment d'exemples à suivre.
L'une des raisons pour lesquelles il'y a un seuil est de s'assurer qu'il y a suffisamment d'exemples, et si c'est le cas, cela rend le problème facile à trouver, parce qu'il'y a quelque chose qui n'a manifestement pas été pris en compte.
Avec des piles symboliques et l'identification des registres, y compris le compteur de programme, et l'identification de la disposition des adresses de l'app, vous pouvez à peu près simplement charger l'app dans un débogueur, en forçant la disposition de son espace d'adressage à correspondre à la disposition de l'ASLR, et cela vous donnera la ligne de code source sur laquelle le crash s'est produit.
Les registres à ce moment-là vous diront quelles sont les valeurs des variables, au moins pour les choses qui sont optimisées dans les registres -- ce qui est la plupart des choses -- et le compteur de programme vous donnera l'instruction machine précise.
Cependant... beaucoup de bugs se produisent à la suite de ce qu'on appelle des défaillances en cascade. Une défaillance en cascade se produit lorsque quelque chose va mal, mais n'est pas attrapé immédiatement, généralement en raison d'une vérification insuffisante des erreurs dans le code.
Un échec en cascade vraiment commun est lorsqu'une allocation de mémoire échoue, qu'un pointeur est assigné à l'allocation échouée (ce qui le rend NULL), et qu'ensuite, potentiellement un long, long moment après les faits, le pointeur est déréférencé comme s'il contenait de la mémoire derrière lui, et un crash se produit (dans Mac OS X, la page 0 est mappée comme inaccessible, pour empêcher quelqu'un d'y allouer une page sans beaucoup de travail, donc cela se manifeste comme un SIGBUS, plutôt qu'un SIGSEGV ; le code d'exception est l'un des codes d'état du processeur qui'est capturé dans le cadre du rapport de crash, puisque le registre d'état est l'un des registres qui est dumpé).
En d'autres termes, cela peut demander beaucoup de travail, mais une fois que vous savez que cela'se produit, cela'est soit évitable, soit au moins vous pouvez attraper l'erreur et faire apparaître un dialogue au lieu de planter.
J'avais l'habitude de travailler sur le noyau de Mac OS X lui-même (c'est aussi le noyau d'iOS). Ces crashs sont considérés comme majeurs graves, mais... bizarrement, ils passent par les mêmes règles de seuil avant d'être envoyés à un ingénieur pour analyse.
Typiquement, sans rapport extérieur, ce sont les choses sur lesquelles vous travaillez quand il n'y a rien d'autre qui'est plus urgent de travailler.
Elles sont généralement très difficiles à trouver.
Et elles sont vraiment gratifiantes, lorsque vous les trouvez, même si la direction ne s'en préoccupe généralement pas, puisqu'elles n'ont pas d'impact sur les plannings, à moins que quelqu'un de l'extérieur passe par les canaux de support pour s'en plaindre.
En d'autres termes : elles ont tendance à être de faible priorité par rapport, par exemple, aux listes de contrôle d'accès qui n'empêchent pas l'accès à quelque chose quand elles le devraient, ou qui empêchent l'accès à quelque chose quand elles ne le devraient pas, etc..
La ligne de fond, cependant : si c'est assez mauvais pour vous que cela'rend les choses inutilisables, et que vous avez besoin d'aide à ce sujet :
Vous devez passer par les canaux d'aide aux développeurs ou aux utilisateurs, plutôt que de compter sur les rapports d'écrasement pour régler les choses par magie pour vous.
Les choses peuvent finir par être "magiquement corrigées", mais vous'ne les connaîtrez jamais, et même si elles sont dans une note de version, vous'ne saurez pas que quelque chose comme "Corriger un bug dans la gestion des descripteurs matériels lorsque le canal Alpha est indiqué présent, mais n'a aucun bit défini dans la première colonne" est la même chose que "Lorsque je clique ici, le programme plante".