O mês 13 está fora dos limites?


23

Recentemente, meu Mac está exibindo mensagens estranhas, como "O mês 13 está fora dos limites".

insira a descrição da imagem aqui

Como corrigir esse erro? Não posso ir ao centro de reparos autorizado da apple ant, porque está muito longe de um centro da Apple


De @tgray: "Comecei a obter o alto uso da CPU hoje por causa do UserEventAgent. Ele também usa uma quantidade enorme de RAM (mais de 30 GB, se eu permitir que ela funcione por tempo suficiente). Forçar o encerramento e a reinicialização não mudaram nada. Fiz uma amostra de o processo e vi muitas linhas lidando com datas. Quando mudei a data para novembro, meu uso da CPU voltou ao normal. No segundo em que mudei para o presente, fiquei doido novamente. Gostaria de saber se isso está relacionado à data do iOS. bug na versão 11.2.1? Espero que a Apple a conserte em breve, porque meu computador está inutilizável. "
JMY1000

Respostas:


10

Este erro está registrado no iOS 11 e no macOS 10.13, com certeza, e não vejo que ele cause qualquer função ou problema específico em qualquer plataforma.

Vou colocar um link para a pergunta principal aqui sobre "o macOS registra demais", já que essa é uma opinião e impressão que vale a pena discutir. Algumas pessoas podem se sentir melhor se não houver mensagens, a menos que uma condição realmente séria precise de ação. Outros querem ainda mais detalhes para saber o que está acontecendo / aprender / medir. Então, será uma troca como esses são problemas / categorizados / usados.

Um desenvolvedor interessante que tem algumas ferramentas é Howard Oakley, que bloga em https://eclecticlight.co/

Sua página de downloads possui dois aplicativos de interesse (use o link de downloads esquerdo, pois as versões do produto abaixo são beta e podem não estar atualizadas em um dia ou semana):

  • Consolation - um navegador de console alternativo
  • Woodpile - uma ferramenta para contar / armazenar / analisar padrões de registro

10

Eu posso verificar a legitimidade desse problema. Eu tive o mesmo problema ontem e, após uma reinicialização, o computador ficou quase inútil devido a esse erro. Por alguma razão, o computador não pode lidar com este mês e gera erros sempre que houver bancos de dados ou listas.

Para corrigir isso:

  1. Abrir Activity Monitor e forçar o encerramento de dois processos: lsd,UserEventAgent

  2. Abra Preferências do Sistema e navegue até "Data e Hora"

  3. Desmarque a opção "Definir data e hora automaticamente"

  4. No calendário, selecione uma data anterior a dezembro de 2017 e pressione Salvar

  5. Se UserEventAgentou lsdcontinuar a causar problemas, force-os novamente após definir a data.

Outras pessoas aqui têm esse problema

Por quê?

Parece-me que o UserEventAgent estava tentando usar dois arquivos plist:

System/Library/LaunchAgents/com.apple.UserEventAgent-Aqua.plist

e

System/Library/LaunchAgents/com.apple.UserEventAgent-LoginWindow.plist

Quando tentou usar as listas, ocorreu um erro:

Month 13 is out of bounds

Não tenho certeza do que realmente aconteceu no UserEventAgent, mas é óbvio que, quando ocorre o erro, ele não pode lidar com ele e causa alto uso de CPU e RAM.


Isso não funciona para mim. Tentei quase três vezes, mas nada acontece.
ninguém usuário

@qwerty Você ainda recebe o erro apesar de ter sua data e hora definidas antes de dezembro de 2017? Idealmente, defina Data e hora como 1º de novembro, depois elimine os processos mencionados acima com o monitor de atividades.
CKacmaster #

Eu até tentei isso antes. Também tentei alterá-lo para 1º de janeiro, mas ainda não funciona. Acho que devo ignorar esse erro porque não tenho alto uso de CPU ou uso de RAM. Espero que a Apple corrija isso na próxima atualização de software. Bem, pelo menos é melhor do que o bug root: macrumors.com/how-to/temporarily-fix-macos-high-sierra-root-bug
ninguém utilizador

(Não posso adicionar um comentário, desculpe.) Comecei a obter o alto uso da CPU hoje devido ao UserEventAgent. Ele também usa uma quantidade enorme de RAM (mais de 30 GB, se eu permitir que funcione por tempo suficiente). Forçar encerramento e reinicialização não mudou nada. Fiz uma amostra do processo e vi várias linhas lidando com datas. Quando mudei a data para novembro, meu uso da CPU voltou ao normal. No segundo que eu mudei para o presente, ele ficou louco novamente. Gostaria de saber se isso está relacionado ao bug de data do iOS na versão 11.2.1? Espero que a Apple o conserte em breve, porque meu computador está inutilizável.
Hmode #

1
@qwerty Não deixe o computador desligar até a Apple corrigir isso. Cometi o erro de reiniciar quando vi pela primeira vez o erro no meu console XCode, e o uso da minha RAM e CPU piorou. Depois de alguma investigação, imaginei que faria o acima para uma solução temporária, como meu computador foi quase inútil. O erro é inofensivo, a menos que você reinicie ou tente carregar os arquivos plist.
Ckacmaster

2

Eu tive o mesmo problema com o uso extremamente alto da CPU e da memória do UserEventAgent a partir do início de dezembro de 2017. O console mostrou o erro "mês fora dos limites", conforme descrito acima.

Tentei o utilitário de disco "primeiros socorros", reinicia, modo de segurança (para limpar o cache do sistema), limpando NVRAM e SMD, nada ajudou. Notei que o uso da CPU e da memória não aumentou no modo de segurança.

Como @tgray e u / kidtexas , em algum momento eu descobri que se desabilitasse todas as minhas opções personalizadas de inicialização, o problema não ocorreria.

Acabei escrevendo o pequeno script abaixo para me ajudar a depurar qual plist estava causando o problema. Acabou sendo uma plist que ocorre no primeiro dia de cada mês:

<key>StartCalendarInterval</key>
<dict>
    <key>Day</key>
    <integer>1</integer>
    <key>Hour</key>
    <integer>03</integer>
    <key>Minute</key>
    <integer>00</integer>
</dict>

Muitas das minhas listas usam a StartCalendarIntervalchave e, usando o script abaixo, eu poderia mostrar que elas não pareciam causar problemas de RAM e memória, então não está totalmente claro para mim por que uma lista específica causa o problema. Independentemente disso, foi assim que eu resolvi.

Eu recomendo fortemente que os leitores examinem o script para tentar entender o que ele faz, em vez de apenas copiar e colar. Especificamente, como está escrito isto só irá funcionar para plists em ~/Library/LaunchAgents(não /Library/LaunchDaemonse outros), e intencionalmente só testa plists cujo nome de arquivo e <key>Label</key>seguem o padrão específico: com.USERNAME.my_plist_name[.plist]. Antes de executá-lo, usei uma linha para bootouttodas as minhas listas: for plist in com."$(whoami)".*.plist; do launchctl bootout gui/"${MYUID}"/"${plist%.plist}" || true; donee verifiquei que elas não apareciam mais nos launchctl listresultados.

#! /bin/bash
# /apple/307512/month-13-is-out-of-bounds

set -euf -o pipefail

MYUID="$(id -u)"

pushd "${HOME}"/Library/LaunchAgents

while IFS= read -r -d '' plist; do
  echo "${plist}"
  stats=($(ps ux | grep -v grep | grep UserEventAgent | awk '{ print $3, $5}'))
  cpu="${stats[0]}"
  vmem="${stats[1]}"
  echo "CPU use and virtual memory size while disabled: ${stats[@]}"
  launchctl bootstrap gui/"${MYUID}" "${plist}"
  sleep 5
  stats=($(ps ux | grep -v grep | grep UserEventAgent | awk '{ print $3, $5}'))
  echo "CPU use and virtual memory size while enabled: ${stats[@]}"
  echo "Change in vmem: $(( "${vmem}" - "${stats[1]}" ))"
  echo
done < <(find . -iname "com.$(whoami).*.plist" -print0)

popd

Nota para as pessoas que executam isso: assume que todos os agentes que estão testando já estão desativados; portanto, execute o bootout(ou similar) recomendado pelo n8henrie.
Ken Williams

1

Como outros, eu estava tendo alto uso de CPU e enorme uso de RAM do UserEventAgent (veja meu comentário acima). Alterar a data para novembro e forçar o encerramento de coisas corrigidas pelo UserEventAgent. Tudo começou no sábado depois que eu reiniciei.

Consertar

Eu descobri isso para mim. Esperançosamente, para outras pessoas com problemas, isso funcionará para você.

O problema era do LaunchAgent que eu tenho em ~ / Library / LaunchAgents. É um arquivo plist simples que chama StartCalendarInterval, que é uma chave válida para o launchd plists. O trabalho LaunchAgent chama um script de shell que copia alguns arquivos para um local de backup no primeiro dia do mês. O trabalho não está sendo chamado - acho que ele foi iniciado verificando os trabalhos carregados no Calendário que está causando o problema. Assim que eu descarreguei esse plist e movi o arquivo para fora do diretório, UserEventAgent estava bem (após uma saída forçada). No segundo em que carreguei o plist (launchctl load xxxx), o UserEventAgent ficou louco.

StartCalendarInterval é uma chave válida para o lançamento, como visto aqui nos documentos da Apple .

Portanto, para qualquer pessoa que tenha problemas, verifique seus diretórios LaunchAgent e procure a chave StartCalendarInterval (ou qualquer outra chave relacionada ao calendário). Não tive nenhum problema com as listas de intervalo com base no tempo.

Nota: Isso não corrige os erros do 'Mês 13 fora dos limites', apenas o comportamento louco do UserEventAgent.


Na verdade, eu não tenho alto uso da CPU do User Event Agent e também não tenho alto uso de ZCPU e RAM.
usuário de ninguém

Essa resposta me ajudou. Embora eu não tenha tido problemas com o UserEventAgent, o lsd ficou louco. Felizmente, lembro que criei o plist com o StartCalendarEvent sozinho. Apenas desativou e matou a força lsd.
Denis The Menace

0

Depois de relatar isso à Apple e escalar a cadeia de escalação, disseram-me que isso deveria ser corrigido no macOS 10.13.3.

Aparentemente, isso é causado por um aplicativo que chama o procedimento NSDate obsoleto 'descriptionWithCalendarFormat' .

Você pode ler mais em https://forums.developer.apple.com/thread/88417 .

Em alguns casos, editar ou remover certos arquivos plist impedirá que os programas chamem o procedimento descontinuado, mas a correção real é uma atualização do sistema operacional.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.