Веб-инспектор аварийно завершает работу в Safari 7

На определенном внутреннем сайте всякий раз, когда я открываю веб-инспектор в Safari 7, он сразу же зависает, а затем происходит сбой всей вкладки. Когда я закрываю разбитую вкладку, я получаю это сообщение в консоли:

1/22/14 10:54:27.896 AM com.apple.launchd[1]: (com.apple.WebKit.WebContent.D50214F7-A6C9-46E5-8F06-71C873A2D4B8[96246]) Exited with code: 1

К сожалению, я не могу поделиться ссылкой или кодом самого сайта, так как он внутренний, но вот некоторые дополнительные сведения:

  • Это происходит на трех разных машинах с Safari 7 на OS X Mavericks.
  • Это сохраняется, даже если я выхожу и перезапускаю Safari 7
  • Этого не происходит, когда я использую инспекторы в любых других браузерах, включая Safari 6 (в OS X Lion)
  • Этого не происходит, когда я использую веб-инспектор Safari 7 на других сайтах.
  • Если я просматриваю сайт в другом браузере (например, Firefox), сообщений об ошибках нет.

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


ОБНОВЛЕНИЕ: Еще одна потенциальная часть головоломки — веб-инспектор дает сбой только тогда, когда я просматриваю сайт вне сервера, а не локально.

Сначала я подумал, что это связано с тем, что я ссылаюсь на Pingdom и Google Analytics с URL-адресами, не зависящими от протокола (которые не разрешаются локально, поэтому они не загружаются), например:

//www.google-analytics.com...

Так что это заставило меня подумать, что что-то в одном из этих скриптов вызвало сбой, что объясняет, почему это произошло только на размещенной странице (где разрешаются пути). Но никаких игральных костей: даже если я добавлю к этим URL-адресам префикс http://, веб-инспектор не рухнет, когда я просматриваю страницу локально, а только за пределами сервера.

Ответы (2)

Я только что исправил точно такую ​​же проблему на сайте. Это раздражает, когда отладчик задыхается, поэтому он не может помочь вам найти проблему!

Моя проблема была вызвана тем, что бродячий класс попал в стиль.

<div style="background: #ffb380; padding-bottom:30px; width:300px; text-center;">

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

  1. Онлайн-проверка ошибок, например, http://www.onlinewebcheck.com/
  2. Отследите проблему, удалив контент со страницы, пока не загрузится веб-инспектор.
Мой HTML проходит проверку. В моем CSS есть одна «ошибка», которая на самом деле связана с тем, что я использую префикс -webkit-в одном конкретном селекторе. И опять же, веб-инспектор не падает, когда я проверяю страницу локально...
Если ваш сервер/локальные страницы используют разные js/html или выполняются немного по-другому, это может объяснить это. Я бы постепенно удалял контент со страницы, чтобы выяснить причину.
См. мое обновление — единственная разница между локальным и серверным заключалась в том, что в локальной версии было два скрипта, которые на самом деле не загружались, поэтому я подумал, что виноваты они. Однако, даже если я загружу их локально, у меня не будет сбоя.
Вы уже пытались найти проблему, удалив содержимое страницы? ИМХО, это единственный способ решить эту проблему.

Сбой должен создать журнал сбоев. Поскольку каждый веб-контент работает в своем собственном процессе. Откройте /Applications/Utilities/Console.app и введите WebContent. это должно показать вам отчет о сбое:

01.30.2014 21:39:20.697 ReportCrash[4191]: отчет о сбое для com.apple.WebKit.WebContent[331] версии 9537 (9537.73.11) сохранен в /Users/UserName/Library/Logs/DiagnosticReports/com. apple.WebKit.WebContent_2014-01-30-213920-1_My-Mac.crash

Там также будет кнопка: введите описание изображения здеськоторую вы можете нажать, чтобы получить более подробную информацию.

в нем вы увидите строки типа:

Crashed Thread:  18  Dispatch queue: CA::CG::Queue

Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000

Application Specific Information:
abort() called

Опубликуйте этот раздел и ветку, в которой он говорит, что произошел сбой. мой пример - поток 18

В теме будет две записи. Тот, который выглядит так:

18  com.apple.HIToolbox             0x00007fff8f7cecb7 ReceiveNextEventCommon + 479

и еще ниже:

Thread 18 Crashed:: Dispatch queue: CA::CG::Queue
0   libsystem_kernel.dylib          0x00007fff96301866 __pthread_kill + 10
1   libsystem_pthread.dylib         0x00007fff8d0f235c pthread_kill + 92
2   libsystem_c.dylib               0x00007fff904adbba abort + 125
3   libGPUSupportMercury.dylib      0x00007fff95e551b6 gpusKillClient + 111
4   libGPUSupportMercury.dylib      0x00007fff95e5651a gpusSubmitDataBuffers + 161
5   com.apple.GeForceGLDriver       0x00001234402eefe1 0x123440000000 + 3076065
6   com.apple.GeForceGLDriver       0x00001234402eee49 0x123440000000 + 3075657
7   com.apple.QuartzCore            0x00007fff9a4f7cf4 CA::CG::Renderer::flush(bool) + 44
8   com.apple.QuartzCore            0x00007fff9a4f4fb5 CA::CG::IOSurfaceQueue::flush_renderer(CA::CG::Queue::FlushMode) + 117
9   com.apple.QuartzCore            0x00007fff9a4f6b5d CA::CG::Queue::render_callback(void*) + 555
10  libdispatch.dylib               0x00007fff9781d2ad _dispatch_client_callout + 8
11  libdispatch.dylib               0x00007fff9781f68f _dispatch_queue_drain + 451
12  libdispatch.dylib               0x00007fff978209dd _dispatch_queue_invoke + 110
13  libdispatch.dylib               0x00007fff9781efa3 _dispatch_root_queue_drain + 75
14  libdispatch.dylib               0x00007fff97820193 _dispatch_worker_thread2 + 40
15  libsystem_pthread.dylib         0x00007fff8d0f2ef8 _pthread_wqthread + 314
16  libsystem_pthread.dylib         0x00007fff8d0f5fb9 start_wqthread + 13

Размещение этих разделов здесь может или не может быть кто-то заметит, в чем ошибка.

Хм... на самом деле вкладка не создает журнал сбоев. Я не вижу в Console.app ничего, что ссылается на WebContent, пока я вручную не закрою разбитую вкладку, которая затем выдаст сообщение, которое я процитировал в своем вопросе.
Хорошо, это того стоило. Если у вас есть веб-проверка, открытая для другой страницы, а затем перейдите к этому URL-адресу, что произойдет. Или, если вы находитесь в консольном представлении веб-инспектора.
Если я это сделаю, все это зависнет до того, как что-либо закончит загрузку, поэтому консоль веб-инспектора не сможет отобразить какие-либо сообщения. Я также заметил, что ни один из процессов «Веб-контент Safari» в «Мониторе активности» не показывает сбоев, поэтому я думаю, поэтому нет журнала сбоев?