La commande shell ...
sample Finder
... surveillera tous les appels de fonction effectués par le Finder et créera un fichier texte montrant les piles d'appels de chacun des threads du Finder. Même les non-programmeurs avertis (super utilisateurs, si vous voulez) peuvent souvent en tirer de précieuses informations. C'est aussi une bonne chose à joindre à un rapport de bogue à Apple via http://bugreport.apple.com/ .
Il s'agit essentiellement de la même chose que le bouton "Exemple de processus" dans le moniteur d'activité.
Mise à jour: Ooh, encore mieux que sample(1)
est spindump(8)
, ce qui est comme , sample
mais ajoute une visibilité sur ce que le noyau fait quand les fils de l'application sont bloqués en attente pour le noyau.
sudo spindump Finder
Le fichier texte qu'il crée /tmp
nécessitera la lecture des privilèges root, car il peut contenir des informations privilégiées.
Plus d'indices pourraient être glanés de ...
lsof -p $PIDOfFinder
(où $ PIDOfFinder est l'ID de processus du Finder, que vous pouvez trouver via ps
.)
Il semble que vous puissiez obtenir ces mêmes informations dans le moniteur d'activité. Sélectionnez Finder, appuyez sur le bouton "Inspecter" et sélectionnez l'onglet "Ouvrir les fichiers et les ports".
Un autre point de données intéressant serait de savoir si le problème se produit ou non pour un nouveau compte utilisateur propre sur le même système. Créez simplement un nouveau compte utilisateur, déconnectez-vous de votre compte normal (n'utilisez pas le changement rapide d'utilisateur - nous ne voulons pas que votre "mauvaise" instance du Finder continue de fonctionner en arrière-plan et prête à confusion) et connectez-vous au nouveau compte propre et voyez si le problème se produit là aussi.
Exécutez-vous des hacks InputManager, y compris des trucs basés sur SIMBL, ou des "haxies" Unsanity Application Enhancer (APE)?
Le problème se produit-il lors du démarrage en "mode sans échec" (c'est-à-dire avec la <shift>
clé enfoncée)?