Crash dans [NSWindow orderFrontRegardless] après la mise à jour vers macOS Mojave

Comment initialisez-vous l'application? NSApplication a-t-il été initialisé avant d'utiliser AppKit ?

Quelque chose comme ces étapes devrait être nécessaire dans main.m:

@autoreleasepool {
    NSApplication* application = NSApplication.sharedApplication;

    AppDelegate* delegate = [[AppDelegate alloc] init];
    application.delegate = delegate;

    [application run];
}

De plus, votre délégué pourrait être désalloué, car NSApp en contient une faible référence.

Il s'avère que j'ai eu un grave bogue de mémoire dans un endroit complètement différent, même pas mentionné dans la trace.

J'étais en train de déréférencer un pointeur non initialisé.

C'est la deuxième fois que cela se produit.

Ne faites pas confiance aux traces d'Apple lors du débogage des erreurs de mémoire.

Même avec libgmalloc.

Vous avez indiqué que vous déréférençiez un pointeur non initialisé. Mais, je n'ai pas assez d'informations dans le rapport que vous avez publié pour savoir si cela était (peut-être par chance) nul, ou simplement de la mémoire. Je suppose qu'à un moment donné, vous avez planté avec un EXC_BAD_ACCESS (l'équivalent du signal est SIGBUS ou SIGSEGV , selon).

L'information critique ici était que vous aviez installé un gestionnaire de signaux.

Les gestionnaires de signaux s'exécutent généralement (mais pas toujours) sur le thread qui plante en utilisant la même pile. Le noyau injecte le gestionnaire en utilisant cette fonction _sigtramp . Lors de la livraison du signal, l'état actuel de la pile contenait les informations dont vous aviez besoin pour détecter le mauvais accès à la mémoire. Mais, votre gestionnaire de signaux a été appelé à la place. Donc, il a fonctionné, mutant la pile comme il l'a fait.

Ensuite, votre gestionnaire de signaux s'est terminé d'une manière ou d'une autre. Il est possible de configurer un gestionnaire de signal en utilisant sigaction de telle sorte que l'état du processus soit restauré au moment juste avant l'événement de crash. Je ne sais pas comment votre gestionnaire de signaux a été configuré. Mais, en fin de compte, je vais supposer que le processus a été autorisé à se terminer.

À ce stade, le ReportCrash d'Apple aurait été déclenché et capturerait les backtraces pour tous les threads quel que soit l'état que votre gestionnaire de signaux les a laissé . Ceci est critique, car ce n'est pas nécessairement l'état de plantage.

Ajoutant de la complexité, backtrace_symbols_fd n'est pas du tout sûr à utiliser à partir d'un gestionnaire de signaux. La sécurité asynchrone est un défi et l'exécution de code à partir d'un gestionnaire de signaux est très difficile à obtenir correctement. Il y a très peu de choses que vous pouvez faire en toute sécurité. Je suis sûr, en plus, que backtrace_symbols_fd alloue de la mémoire. Donc, si votre plantage se trouvait quelque part dans l'allocateur de mémoire, et qu'il semble que c'était le cas, vous couriez certainement un risque de blocage. À en juger par le retour en arrière, il semble que c'est exactement ce qui aurait pu se passer. Consultez man sigaction pour plus de détails.

Pire encore, dérouler la pile sur une trame de gestionnaire de signaux est particulièrement difficile à cause de la magie que fait le noyau pour exécuter votre gestionnaire. C'est pourquoi ce cadre ??? est là.

Un résumé:

Sans un gestionnaire de signal installé, ReportCrash d'Apple aurait produit un retour arrière correct (et probablement utile) pour le thread en panne.

La trace de pile que vous avez incluse n'est pas excellente, mais il est difficile de savoir exactement pourquoi. Il semble que backtrace_symbols_fd n'a pas fait un bon travail de déroulement, peut-être parce qu'il était inapproprié à utiliser à partir d'un gestionnaire de signaux, peut-être parce qu'il n'est pas soutenu par un mécanisme de déroulement de pile suffisant pour cette situation. Mais, sans plus d'informations, il m'est difficile de savoir. Je suis surpris que le cadre supérieur soit _sigtramp , cependant. Cela n'a pas beaucoup de sens. Cela me fait penser que quelque chose ne va pas dans le gestionnaire de signaux lui-même. Il est possible de planter une deuxième fois dans votre gestionnaire.

Les backtraces d'Apple (générées par ReportCrash, backtrace_symbols_fd ou callStackReturnAddresses de NSThread, par exemple) peuvent certainement être fiables, à condition que vous soyez prudent de les utiliser dans des contextes sûrs.