processo icdd consumindo memória substancial no macOS

Na semana passada, o processo 'icdd' foi iniciado periodicamente e, quando o faz, consome uma quantidade enorme de RAM (mais de 7 GB). Quando isso acontece, meu MacBook Pro se torna essencialmente inoperante até que eu possa abrir o Activity Monitor e forçar o encerramento do processo.

Anexei uma captura de tela do monitor de atividades mostrando o icdd usando mais de 7 GB de RAM e fazendo a pressão da memória disparar.

Alguém sabe o que é esse processo ou como posso impedir que esse problema ocorra a cada 30 minutos ou mais?

Eu trabalho com um consultor técnico sênior da Apple nessa questão há mais de um ano e trabalhava com outro consultor sênior há algum tempo antes disso. Fizemos "captura de dados" para enviar aos engenheiros da Apple em várias ocasiões e gravações de tela em várias ocasiões para demonstrar o que está acontecendo no Activity Monitor, no Image Capture e, finalmente, em uma lista que o icdd mantém em / Users / user_name / Library / Application Support / icdd / deviceInfoCache.plist (exibindo-o no Xcode).

Neste ponto, aqui está minha melhor estimativa do que está acontecendo:

O processo icdd (Image Capture Device Database) vê os scanners entrarem e saírem em uma rede ocupada. Ele tenta manter uma lista de seus arquivos de ícone em uma tabela de hash, que também grava no arquivo deviceInfoCache.plist mencionado acima. Sim - isso parece loucura - está mantendo referências aos arquivos de ícone dos scanners. Mas o mais louco é que, por algum motivo, quase todas as entradas deste arquivo apontam para arquivos .icns que não existem. Dos vários sistemas que eu observei, existem muitos milhares de entradas no arquivo, mas apenas alguns dos arquivos .icns existiam em uma das máquinas e nenhum nos outros. Acredito que quando esse arquivo fica grande, o icdd gasta muito tempo tentando verificar a existência de entradas no arquivo .plist e modificá-lo. Eu acredito nisso por duas razões. Primeiro, quando levo meu laptop para casa, o processo icdd às vezes continua sendo executado em cerca de 100% de uma CPU, mas quando eu o mato, ele volta ao "normal" aproximadamente de 0,0 a 0,1%, todas as vezes. Por isso, acho que às vezes ainda está tentando processar informações sobre as entradas quando as abro em casa. Mas quando eu o mato na rede ocupada, ele geralmente volta a quase 100% imediatamente. Quando o número de scanners mostrados no Image Capture diminui (o que geralmente ocorre, mas periodicamente aumenta por algum motivo), o icdd acaba se acalmando. Segundo, a exclusão do arquivo deviceInfoCache.plist faz com que o icdd se comporte razoavelmente por um curto período de tempo - até que o número de entradas seja acumulado novamente. Observe que o icdd mantém uma cópia dessas entradas na memória; portanto, se você excluir o arquivo da conta de usuário, o icdd apenas o reescreve imediatamente. E claro, você não pode matar o icdd por tempo suficiente para excluir o arquivo; portanto, é necessário sair e excluir o arquivo de outra conta de administrador através do terminal. O icdd recriará o arquivo quando você efetuar login novamente, mas terá relativamente poucas entradas e se comportará bem por um tempo.

Para dar uma idéia das escalas, os engenheiros da Apple ficaram chocados ao ver que eu tinha até 85 scanners exibidos no Image Capture. Muitas vezes, no entanto, esse número é estabelecido em cerca de 6 no mesmo sistema e durante os mesmos prazos. O arquivo deviceInfoCache.plist teve entre 8.000 e 12.600 entradas nos sistemas que eu observei que tiveram problemas com o icdd - o meu é o maior e acredito que isso foi transferido de uma máquina mais antiga desde que eu estava tendo problemas com o icdd desde a instalação do meu novo MacBook Pro em dezembro de 2016. Quando excluí o arquivo plist, o número de entradas iniciais no arquivo recém-criado era 44 e, por alguns dias, o uso da cpu icdd pairou perto de 0,0%. No entanto, após cerca de 5 dias no campus, meu arquivo plist possui 964 entradas, e o uso da CPU icdd retornará rotineiramente entre 30% e 90% na rede ocupada da universidade. Quando estou em casa, o arquivo plist aumentará seu número de entradas em 0 a 2 ao longo de um dia. Das 12.600 entradas no meu arquivo plist anterior, apenas 2 delas contêm um "deviceName", o restante contém uma "iconPathLocation", todas apontando para arquivos .icns inexistentes. Com o plist atual, ainda existem exatamente 2 entradas que contêm um "deviceName" e o restante contém um "iconPathLocation" que não existe. todos apontam para arquivos .icns inexistentes. Com o plist atual, ainda existem exatamente 2 entradas que contêm um "deviceName" e o restante contém um "iconPathLocation" que não existe. todos apontam para arquivos .icns inexistentes. Com o plist atual, ainda existem exatamente 2 entradas que contêm um "deviceName" e o restante contém um "iconPathLocation" que não existe.

Portanto, a solução a curto prazo é excluir o arquivo plist de outra conta de administrador via terminal enquanto estiver desconectado da sua conta de usuário. Felizmente, com essas informações agora sendo fornecidas aos engenheiros da Apple pelo meu consultor sênior, os engenheiros da Apple terão informações suficientes para descobrir por que o icdd está agindo dessa maneira e resolver o problema. Obviamente, provavelmente ajudaria se você pudesse verificar minha solução de curto prazo e continuar relatando o que encontrou para a Apple.

Eu tenho lidado com esse problema há um tempo e tenho verificado em todos os lugares! É frustrante ... Finalmente encontrei um link para parar essa loucura estúpida. Não tenho certeza se essa é a fonte do problema, mas pode pará-lo. Aqui estão os passos:

1) desativar SIP ( link )

2) digite os seguintes comandos:

cd / Aplicações

sudo mv Image \ Capture.app/ Desativar \ Image \ Capture.app/

cd / Sistema / Biblioteca / Imagem \ Captura / Suporte /

sudo mv icdd icdd-disable

3) reiniciar

4) ative o SIP se você se importa

Link original: https://havecamerawilltravel.com/photographer/prevent-photos-app-mac-osx

Espero que ajude.

Eu tenho lutado com esse problema também. Não encontrando respostas on-line e não querendo mexer com o terminal, liguei para o Suporte da Apple. Inicialmente, eles pensaram que meu HD estava corrompido (foi - foi corrigido, mas não solucionou o problema). O problema persistiu depois de aumentar minha RAM. Solicitado por um comentário da Internet sobre pesquisas de scanner de rede, notei que o ICDD só ficaria louco quando o Wi-Fi estivesse ativado. Se eu desconectasse o Wi-Fi e fechasse o ICDD, ele não reiniciaria e aumentaria o uso de RAM ou CPU (até que o Wi-Fi fosse reativado).

Liguei novamente para o Suporte da Apple, que parece ter corrigido o problema, redefinindo o SMC e a NVRAM. Agora, o ICDD é executado em um nível baixo (10 a 20 MB), em vez de consumir mais de 10 GB de RAM. Adicionei links abaixo para fazer isso, mas recomendo ligar para o Suporte da Apple para o seu problema específico.

A explicação deles para o porquê disso está acontecendo tinha a ver com a minha RAM entupida ou cheia de caches na Internet, etc. Por que agora se tornou aparente e se está associado ao Sierra, não sei dizer.

Espero que isso ajude algumas pessoas!

Redefinir SMC: https://support.apple.com/en-us/ht201295

Redefinir NVRAM: https://support.apple.com/en-us/ht204063

10-15mins fix.

Minhas especificações:

• início de 2011 MacBook Pro de 13 "
• SSD Samsung de 500 GB (atualizado há ~ 1.5 anos)
• 8 GB de RAM (atualizado ~ 1 mês atrás)
• macOS Sierra 10.12.3 (até
• Parallels 10 com Windows 10 para software SAS

Embora as respostas acima forneçam melhores dados técnicos, gostaria de adicionar uma observação geral.

O que estamos lidando é provavelmente um péssimo software, que carrega bugs antigos por anos, que não foi testado corretamente e provavelmente nunca será corrigido. Isso é tudo. Na última década, a engenharia de software da Apple está se deteriorando de forma constante, e temos que suportar esses cenários o tempo todo.

Normalmente, redefinir essas peças de software para o estado original (por exemplo, excluindo caches e arquivos de configuração, .plists ou até redefinindo os padrões de usuário) facilitaria o problema por algum tempo.

Outra maneira é redefinir o subsistema relacionado ao SO. Neste caso, por exemplo, permitirá "redefinir o sistema de impressão", o que provavelmente limpará a cabeça do icdd por um tempo - mas forçará você a configurar seu ambiente de impressão novamente.

E, é claro, a abertura de novas entradas RADR para a Apple poderá, eventualmente, chamar a atenção para o subsistema com defeito.