26

Кто-нибудь знает, есть ли практический способ определить причину «Aw Snap!сообщение, которое иногда появляется в Google Chrome? Есть ли в Chrome журнал ошибок, на который я могу сослаться? Я подозреваю, что эта проблема вызвана рекурсивным циклом в коде, который затем поглощает всю память? Есть ли способ, которым я могу это подтвердить?

3 ответа3

25

Вот, смотрите объяснения здесь: для обычной регистрации в Chrome, вы можете попробовать:

24

Официальная учетная запись Twitter для разработчиков Chrome, связанная с веб-сайтом, который помогает вам отлаживать страницы "Aw snap": http://www.chromium.org/for-testers/enable-logging

Рекомендуется запустить Chrome с такими флагами:

--enable-logging --v=1

Если вы сделаете это, то вы можете получить журнал сбоев из файла chrome_debug.log в каталоге пользовательских данных Chrome (в родительском каталоге Default/) или в папке двоичной сборки (out\Debug), если вы используете отладочную сборку ,

1

Ой, Snap! Страница обычно связана с ошибкой ошибки сегментации процесса, которая может быть связана с ошибкой программного обеспечения. Чтобы определить причину, вы можете включить ведение журнала (как предложено в других ответах) или проанализировать обратную трассировку файла дампа ядра (в macOS, Linux, например, Ubuntu).

Если вы не знаете причину (например, трассировка стека состоит только из адресов памяти), вы можете создать новый тикет поддержки в системе отслеживания ошибок Chrome (или дважды проверить, существует ли он уже). При составлении отчетов вы должны загрузить и включить Crash ID, перейдя в chrome://crashes/ page, чтобы адреса памяти могли быть преобразованы в символы отладки сопровождающими Chrome.

В качестве альтернативы вы можете декодировать аварийные дампы самостоятельно.

См. Также: Где находится Google Chrome Crash Dump?


Чтобы упростить вышесказанное, вот основные причины сбоя страницы:

  • Вы нашли ошибку (на веб-сайте или в веб-браузере).

    • Ошибка сайта

      • Пример: виртуальная машина JavaScript достигла максимально выделенной памяти (сбой из-за нехватки памяти).

        Чтобы проверить это, запустите DevTools и откройте вкладку Память . Если это так, код должен автоматически приостанавливаться непосредственно перед возможным сбоем нехватки памяти (например, ошибка 810015). Если это так, сообщите о проблеме владельцу веб-сайта или профилируйте код JS, чтобы найти ошибку.

    • Ошибка браузера

      • Рассмотрите возможность отключения расширений или запуска в режиме инкогнито .
      • Рассмотрите возможность удаления кэшированных файлов .
      • Сообщить об ошибке .
      • Переустановите браузер.
      • Используйте другую версию Chrome, такую как Chromium, Dev или Canary channel.
      • Используйте другой браузер, такой как Epic, Firefox, Opera, Brave, Waterfox, Torch или другие.
      • Если проблема повторяется, вы можете попытаться пересобрать исходные коды Chrome с помощью символов отладки и проанализировать трассировку стека или сообщить о ней.
  • Вы достигли максимального количества открытых файлов в вашей системе (см .: # 787381).

    В Linux/Unix/macOS, чтобы проверить это, запустите:

    sysctl -a | grep files
    

    и проверьте, достигло ли kern.num_files предела kern.maxfiles .

    Если это так, увеличьте лимит, выполнив следующие команды:

    sysctl -w kern.maxfiles=20480
    which launchctl && launchctl limit maxfiles 65536 unlimited
    which ulimit && ulimit -c unlimited
    
  • Вы можете иметь некоторые вредоносные программы / вирусы, которые изменяют ваши файлы Chrome, вызывая сбой.

  • У вас может быть проблема с аппаратной памятью . Так что запустите какой-нибудь тест (например, memtest).

Macos

Чтобы отобразить журналы из Chrome, запустите:

log stream --level debug --predicate 'processImagePath contains "Google"'

или запустив консольное приложение, где вы также можете проверить наличие аварийных дампов (или проверить в ~/Library/Logs/DiagnosticReports). Смотрите: Отладка «Ой, Snap!»ошибка в Chrome


отладка

Если ничего из вышеперечисленного не поможет, вы можете подумать о компиляции Chrome из исходного кода (это занимает много времени), а затем запустить его непосредственно из терминала. После этого каждый «Aw, Snap!» за ошибкой должна следовать полная трассировка стека, включая функции и строку в файле исходного кода, где это произошло.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .