¿El mes 13 está fuera de límites?

23

Recientemente, mi Mac muestra algunos mensajes extraños como "El mes 13 está fuera de límites".

ingrese la descripción de la imagen aquí

¿Cómo soluciono este error? No puedo ir al centro de reparación autorizado de Ant Apple porque está muy lejos de un centro de Apple

nadie usuario
fuente
De @tgray: "Hoy comencé a usar mucho la CPU debido a UserEventAgent. También usa una gran cantidad de RAM (más de 30 GB si lo dejo correr lo suficiente). Forzar el cierre y el reinicio no cambiaron nada. Hice una muestra de el proceso y vi un montón de líneas relacionadas con las fechas. Cuando cambié la fecha a noviembre, el uso de mi CPU volvió a la normalidad. En el segundo que lo cambié al presente, volvió a enloquecer. Me pregunto si esto está relacionado con la fecha de iOS error en 11.2.1 "Espero que Apple lo corrija pronto porque mi computadora no se puede usar".
JMY1000

Respuestas:

10

Este error se registra en iOS 11 y en macOS 10.13 con seguridad y no veo que cause ninguna función o problema específico en ninguna plataforma.

Voy a vincular a la pregunta principal aquí acerca de "¿MacOS registra demasiado?", Ya que esa es una opinión e impresión que es digna de discusión. Algunas personas pueden sentirse mejor si no hay mensajes a menos que una condición realmente grave necesite acción. Otros quieren aún más detalles para poder saber lo que está sucediendo / aprender / medir. Por lo tanto, va a ser una compensación cómo estos son problemas / categorizados / utilizados.

Un desarrollador interesante que tiene algunas herramientas es Howard Oakley, quien bloguea en https://eclecticlight.co/

Su página de descargas tiene dos aplicaciones de interés (use el enlace de descargas izquierdo, ya que las versiones de productos a continuación son beta y pueden no estar actualizadas en un día o una semana):

  • Consolation : un navegador de consola alternativo
  • Pila de madera : una herramienta para contar / bin / analizar patrones de registro
bmike
fuente
10

Puedo verificar la legitimidad de este problema. Tuve el mismo problema ayer, y después de un reinicio, la computadora quedó casi inútil debido a este error. Por alguna razón, la computadora no puede lidiar con este mes y arroja errores donde haya bases de datos o listas.

Para arreglar esto:

  1. Abrir el Monitor de Actividad y forzar la salida de dos procesos: lsd,UserEventAgent

  2. Abra Preferencias del sistema y navegue hasta "Fecha y hora"

  3. Desmarca "Establecer fecha y hora automáticamente"

  4. En el calendario, seleccione una fecha anterior a diciembre de 2017 y presione Guardar

  5. Si UserEventAgento lsdcontinúa causando problemas, forzarlo a salir nuevamente después de establecer la fecha.

Otras personas aquí tienen este problema

¿Por qué?

Me parece que UserEventAgent estaba intentando usar dos archivos plist:

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

y

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

Cuando trató de usar las listas, obtuvo un error:

Month 13 is out of bounds

No estoy seguro de lo que sucedió realmente en UserEventAgent, pero es obvio que cuando recibe el error, no puede solucionarlo y causa un alto uso de CPU y RAM.

Ckacmaster
fuente
Esto no funciona para mí, lo intenté casi tres veces, pero no pasa nada.
nobody user
@qwerty ¿Aún recibe el error a pesar de haber configurado su fecha y hora antes de diciembre de 2017? Idealmente, establezca la Fecha y Hora en 1 de noviembre, luego elimine los procesos mencionados anteriormente con el monitor de actividad.
Ckacmaster
Incluso intenté eso antes. También intenté cambiarlo al 1 de enero, pero todavía no funciona. Creo que debería ignorar este error porque no tengo un uso elevado de CPU o RAM. Espero que Apple arregle esto en la próxima actualización de software. Bueno, al menos esto es mejor que el error raíz: macrumors.com/how-to/tempomporary-fix-macos-high-sierra-root-bug
nadie usuario
(No puedo agregar un comentario, lo siento). Hoy comencé a usar mucho la CPU debido a UserEventAgent. También utiliza una gran cantidad de RAM (más de 30 GB si lo dejo correr el tiempo suficiente). Forzar el cierre y el reinicio no cambió nada. Hice una muestra del proceso y vi un montón de líneas relacionadas con las fechas. Cuando cambié la fecha a noviembre, el uso de mi CPU volvió a la normalidad. En el segundo que lo cambié al presente, volvió a enloquecer. Me pregunto si esto está relacionado con el error de fecha de iOS en 11.2.1. Espero que Apple lo arregle pronto porque mi computadora no se puede usar.
hmode
1
@qwerty No dejes que tu computadora se apague hasta que Apple parche esto. Cometí el error de reiniciar cuando vi por primera vez el error en mi consola XCode, y mi uso de RAM y CPU empeoró. Después de una investigación, pensé que haría lo anterior para una solución temporal, ya que mi computadora fue casi inútil El error es mayormente inofensivo a menos que reinicie o intente cargar cualquier archivo plist.
Ckacmaster
2

Tuve el mismo problema con el uso extremadamente alto de CPU y UserEventAgent a principios de diciembre de 2017. La consola mostró el error "mes fuera de límites" como se describió anteriormente.

Intenté la utilidad de disco "primeros auxilios", reinicios, modo seguro (para borrar la memoria caché del sistema), borrar NVRAM y SMD, nada ayudó. Me di cuenta de que el uso de CPU y memoria no aumentó en modo seguro.

Al igual que @tgray y u / kidtexas , en algún momento descubrí que si deshabilitaba todas mis listas de lanzamiento personalizadas, el problema no ocurriría.

Finalmente escribí el pequeño script a continuación para ayudarme a depurar qué plist estaba causando el problema. Terminó siendo un plist que se ejecuta el primero de cada mes:

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

Muchos de mis plists usan la StartCalendarIntervalclave, y usando el script a continuación podría mostrar que no parecen causar problemas de RAM y memoria, por lo que no está del todo claro por qué una lista específica causa el problema. De todos modos, así es como lo resolví.

Recomiendo encarecidamente a los lectores que revisen el guión para tratar de comprender lo que hace en lugar de simplemente copiar y pegar. Específicamente, como está escrito esto sólo funcionará para plists en ~/Library/LaunchAgents(no /Library/LaunchDaemonsy otros), y intencionalmente Sólo las pruebas plists cuyo nombre de archivo y <key>Label</key>siguen el patrón específico: com.USERNAME.my_plist_name[.plist]. Antes de ejecutarlo, utilicé una línea para bootouttodos mis plists: for plist in com."$(whoami)".*.plist; do launchctl bootout gui/"${MYUID}"/"${plist%.plist}" || true; doney luego verifiqué que ya no aparecían en los 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
n8henrie
fuente
Nota para las personas que ejecutan esto: se supone que todos los agentes que está probando ya están deshabilitados, así que tenga cuidado de ejecutar el bootout(o similar) que n8henrie recomienda.
Ken Williams
1

Al igual que otros, tenía un alto uso de CPU y un gran uso de RAM de UserEventAgent (vea mi comentario más arriba). Cambiar la fecha a noviembre y forzar el cierre de UserEventAgent corrigió cosas. Todo esto comenzó el sábado después de reiniciar.

Fijar

Me di cuenta de esto por mí. Con suerte para otros con problemas, esto funcionará para usted.

El problema era una lista de LaunchAgent que tengo en ~ / Library / LaunchAgents. Es un archivo plist simple que llama a StartCalendarInterval, que es una clave válida para las listas de inicio. El trabajo LaunchAgent llama a un script de shell que copia algunos archivos a una ubicación de copia de seguridad el primer día del mes. El trabajo no se llama en absoluto; creo que se inicia comprobando los trabajos cargados en el calendario que está causando el problema. Tan pronto como descargué este plist y moví el archivo fuera del directorio, UserEventAgent estuvo bien (después de un cierre forzado). En el segundo en que cargué el plist (launchctl load xxxx), UserEventAgent se volvió loco.

StartCalendarInterval es una clave válida para launchd como se ve aquí en los documentos de Apple .

Entonces, para cualquier persona que tenga problemas, revise sus directorios de LaunchAgent y busque la clave StartCalendarInterval (o cualquier otra clave relacionada con el calendario). No tuve ningún problema con las listas de intervalos basadas en el tiempo.

Nota: Esto no soluciona los errores 'Mes 13 fuera de límites', solo el comportamiento loco de UserEventAgent.

hmode
fuente
En realidad, no uso mucho la CPU del Agente de eventos de usuario, y tampoco tengo un uso elevado de ZCPU y RAM.
Nadie usuario
Esta respuesta me ayudó. Aunque no tuve problemas con UserEventAgent pero lsd se volvió loco. Afortunadamente, recuerdo que creé plist con StartCalendarEvent por mí mismo. Solo lo deshabilité y lsd maté a la fuerza.
Denis The Menace
0

Después de informar esto a Apple y escalar la cadena de escalamiento, me dijeron que esto debería solucionarse en macOS 10.13.3.

Aparentemente, esto es causado por una aplicación que llama al procedimiento NSDate en desuso 'descriptionWithCalendarFormat' .

Puede leer más en https://forums.developer.apple.com/thread/88417 .

En algunos casos, editar o eliminar ciertos archivos plist evitará que los programas llamen al procedimiento obsoleto, pero la solución real es una actualización del sistema operativo.

Phillip Remaker
fuente