Месяц 13 выходит за пределы?


23

Недавно на моем Mac появились странные сообщения, такие как «Месяц 13 вышел за пределы».

введите описание изображения здесь

Как исправить эту ошибку? Я не могу обратиться в авторизованный сервисный центр Ant Apple, потому что он находится очень далеко от Apple.


От @tgray: «Я начал получать высокую загрузку ЦП сегодня из-за UserEventAgent. Он также использует огромный объем ОЗУ (30+ ГБ, если я позволю ему работать достаточно долго). Принудительный выход и перезагрузка ничего не изменили. Я сделал пример процесс и увидел тонну строк, имеющих дело с датами. Когда я изменил дату на ноябрь, мое использование процессора вернулось к нормальному состоянию. Во-вторых, когда я изменил его на настоящее, оно снова пошло на убыль. Интересно, связано ли это с датой iOS ошибка в 11.2.1? Я надеюсь, что Apple исправит это в ближайшее время, потому что мой компьютер не работает ".
JMY1000

Ответы:


10

Эта ошибка регистрируется в iOS 11 и macOS 10.13, и я не вижу, чтобы она вызывала какую-либо конкретную функцию или проблему на любой платформе.

Здесь я приведу основной вопрос о том, «слишком ли много в MacOS регистрируется», так как это мнение и впечатление заслуживают обсуждения. Некоторые люди могли бы чувствовать себя лучше, если бы не было сообщений, если действительно серьезное состояние не требует действий. Другие хотят еще больше деталей, чтобы они могли знать, что происходит / учиться / измерять. Таким образом, это будет компромисс, как эти проблемы / классифицировать / использовать.

Одним из интересных разработчиков, у которого есть некоторые инструменты, является Говард Окли, который ведет блог на https://eclecticlight.co/

На его странице загрузок есть два интересующих приложения (используйте левую ссылку для загрузки, поскольку приведенные ниже версии продукта являются бета-версиями и могут не обновляться в течение дня или недели):


10

Я могу проверить законность этой проблемы. Вчера у меня была такая же проблема, и после перезагрузки компьютер стал почти бесполезным из-за этой ошибки. По какой-то причине компьютер не может справиться с этим месяцем и выдает ошибки везде, где есть базы данных или списки.

Чтобы исправить это:

  1. Open Activity Monitor и силы бросить два процесса: lsd,UserEventAgent

  2. Откройте Системные настройки и перейдите к «Дата и время»

  3. Снимите флажок «Установить дату и время автоматически»

  4. В календаре выберите дату до декабря 2017 года и нажмите Сохранить

  5. Если UserEventAgentили lsdпродолжают вызывать проблемы, то принудительно закройте их снова после установки даты.

Другие люди здесь имеют эту проблему

Зачем?

Мне кажется, UserEventAgent пытался использовать два plist-файла:

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

а также

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

Когда он попытался использовать списки, он получил ошибку:

Month 13 is out of bounds

Я не уверен, что на самом деле произошло в UserEventAgent, но очевидно, что когда он получает ошибку, он не может с ней справиться и вызывает высокую загрузку ЦП и ОЗУ.


Это не работает для меня, я попробовал почти три раза, но ничего не происходит.
никто не пользователь

@qwerty Вы все еще получаете сообщение об ошибке, несмотря на то, что ваша дата и время установлены до декабря 2017 года? В идеале установите дату и время на 1 ноября, а затем завершите процессы, упомянутые выше, с помощью монитора активности.
Ckacmaster

Я даже пробовал это раньше. Я также попытался изменить его на 1 января, но он все еще не работает, я думаю, что я должен просто проигнорировать эту ошибку, потому что у меня нет высокой загрузки ЦП или ОЗУ. Я надеюсь, что Apple исправит это в следующем обновлении программного обеспечения. Ну, по крайней мере, это лучше, чем ошибка root: macrumors.com/how-to/temporary-fix-macos-high-sierra-root-bug
никто не

(Я не могу добавить комментарий, извините.) Сегодня я начал получать высокую загрузку процессора из-за UserEventAgent. Он также использует огромный объем оперативной памяти (более 30 ГБ, если я позволю ему работать достаточно долго). Принудительный выход и перезагрузка ничего не изменили. Я сделал образец процесса и увидел тонну строк, связанных с датами. Когда я изменил дату на ноябрь, загрузка моего процессора нормализовалась. В тот момент, когда я сменил его на настоящее, он снова помешался. Интересно, это связано с ошибкой даты iOS в 11.2.1? Я надеюсь, что Apple исправит это в ближайшее время, потому что мой компьютер не работает.
hmode

1
@qwerty Не позволяйте компьютеру выключаться, пока Apple не исправит это. Я допустил ошибку при перезапуске, когда впервые увидел ошибку в консоли XCode, и использование ОЗУ и ЦП изменилось в худшую сторону. После некоторого исследования я решил, что для временного решения сделаю то же самое, что и мой компьютер. был почти бесполезен. Ошибка в основном безвредна, если вы не перезапустите или не попытаетесь загрузить какие-либо файлы plist.
Ckacmaster

2

У меня была такая же проблема с чрезвычайно высоким использованием процессора UserEventAgent и использованием памяти, начиная с начала декабря 2017 года. Консоль показала ошибку «Месяц вне границ», как описано выше.

Я пробовал дисковую утилиту «Первая помощь», перезагрузки, безопасный режим (для очистки системного кэша), очистки NVRAM и SMD, ничего не помогло. Я заметил, что использование процессора и памяти в безопасном режиме не увеличилось.

Как и @tgray и u / kidtexas , в какой-то момент я понял, что если я отключу все свои собственные списки запуска, проблема не возникнет.

В конце концов я написал небольшой скрипт ниже, чтобы помочь мне отладить, какой plist вызывал проблему. В итоге получился список, который запускается первого числа каждого месяца:

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

Многие из моих списков используют StartCalendarIntervalключ, и, используя приведенный ниже сценарий, я мог показать, что они, похоже, не вызывают скачков памяти и памяти, поэтому мне не совсем понятно, почему один конкретный список причин проблемы. Независимо от того, как я с этим разобрался.

Я настоятельно рекомендую читателям просмотреть сценарий, чтобы попытаться понять, что он делает, а не просто копировать и вставлять. В частности, как написано это будет работать только для plists в ~/Library/LaunchAgents(не /Library/LaunchDaemonsи других), и он намеренно проверяет только plists чьего имени файла и <key>Label</key>следовать шаблону конкретного: com.USERNAME.my_plist_name[.plist]. Перед запуском я использовал однострочник для bootoutвсех моих списков for plist in com."$(whoami)".*.plist; do launchctl bootout gui/"${MYUID}"/"${plist%.plist}" || true; done, а затем убедился , что они больше не отображаются в launchctl listрезультатах.

#! /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

Примечание для людей, выполняющих это: предполагается, что все агенты, которые он тестирует, уже отключены, поэтому bootoutбудьте внимательны, чтобы запустить (или аналогичный), который рекомендует n8henrie.
Кен Уильямс

1

Как и у других, у меня было высокое использование процессора и огромное использование оперативной памяти от UserEventAgent (см. Мой комментарий выше). Измените дату на ноябрь и принудительно завершите работу с UserEventAgent. Все началось в субботу после перезагрузки.

Fix

Я понял это для меня. Надеюсь, для других, у кого есть проблемы, это будет работать для вас.

Проблема была в списке LaunchAgent, который у меня есть в ~ / Library / LaunchAgents. Это простой plist-файл, который вызывает StartCalendarInterval, который является допустимым ключом для launchd plists. Задание LaunchAgent вызывает сценарий оболочки, который копирует некоторые файлы в резервное хранилище в первый день месяца. Задание вообще не вызывается - я думаю, что оно запускается, проверяя загруженные задания по календарю, который вызывает проблему. Как только я выгрузил этот список и переместил файл из каталога, UserEventAgent был в порядке (после принудительного выхода). Когда я загрузил plist (launchctl load xxxx), UserEventAgent сошел с ума.

StartCalendarInterval является действительным ключом для запуска, как показано здесь в документации Apple .

Так что для тех, у кого есть проблемы, проверьте свои каталоги LaunchAgent и найдите ключ StartCalendarInterval (или любой другой ключ, связанный с календарем). У меня не было проблем со списками интервалов времени.

Примечание: это не исправляет ошибки «Месяца 13 вне пределов», только сумасшедшее поведение UserEventAgent.


На самом деле у меня нет высокой загрузки ЦП User Event Agent. И у меня также нет высокой загрузки ZCPU и оперативной памяти.
никто не

Этот ответ помог мне. Хотя у меня не было проблем с UserEventAgent, но lsd сошел с ума. К счастью, я помню, что я создал plist с StartCalendarEvent самостоятельно. Просто отключил его и принудительно убил lsd.
Денис Угроза

0

После сообщения об этом в Apple и масштабирования цепочки эскалации мне сказали, что это должно быть исправлено в macOS 10.13.3.

По-видимому, это вызвано тем, что приложение вызывает устаревшую процедуру NSDate «descriptionWithCalendarFormat» .

Вы можете прочитать больше на https://forums.developer.apple.com/thread/88417 .

В некоторых случаях редактирование или удаление определенных файлов plist не позволит программам вызывать устаревшую процедуру, но реальное исправление - это обновление ОС.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.