O comando shell ...
sample Finder
... monitorará todas as chamadas de função feitas pelo Finder e criará um arquivo de texto mostrando as pilhas de chamadas de cada um dos threads do Finder. Mesmo não programadores com conhecimento (super usuários, se preferir) podem obter informações valiosas sobre isso. Também é ótimo anexar um relatório de bug à Apple via http://bugreport.apple.com/ .
É basicamente o mesmo que o botão "Processo de amostra" no Monitor de atividades.
Atualização: Ooh, ainda melhor do que sample(1)
é spindump(8)
, o que é parecido, sample
mas adiciona visibilidade ao que o kernel está fazendo quando os threads do aplicativo são bloqueados esperando pelo kernel.
sudo spindump Finder
O arquivo de texto em que ele cria /tmp
exigirá leitura de privilégios de raiz, pois pode conter informações privilegiadas.
Mais pistas podem ser obtidas de ...
lsof -p $PIDOfFinder
(onde $ PIDOfFinder é o ID do processo do Finder, que você pode encontrar via ps
.)
Parece que você pode obter as mesmas informações no Activity Monitor. Selecione Finder, clique no botão "Inspecionar" e selecione a guia "Abrir arquivos e portas".
Outro ponto de dados interessante seria se o problema ocorre ou não para uma conta de usuário nova e limpa no mesmo sistema. Basta criar uma nova conta de usuário, sair da sua conta normal (não use a Troca rápida de usuário - não queremos que sua instância "ruim" do Finder continue sendo executada em segundo plano e confunda coisas) e entre no nova conta limpa e veja se o problema também acontece lá.
Você está executando algum hacker do InputManager, incluindo material baseado em SIMBL ou "haxies" do Unsanity Application Enhancer (APE)?
O problema ocorre quando inicializado no "Modo de segurança" (isto é, inicializado com a <shift>
tecla pressionada)?