Эта тема для постоянно возникающих одних и тех же вопросов по поводу ошибок в работе Logic Pro 9, поиска их причин и последующего решения. На истину в последней инстанции не претендую, но статья опишет мой собственный успешный опыт в решении проблем. Также, уважаемые сообщники могут дополнять этот топик своими примерами устранения ошибок, чтобы помочь другим пользователям, и, конечно же, спрашивать о неполадках, возникающих у вас, и пока не имеющих решения – совершенно не возбраняется. В статье нет волшебных таблеток, но представлен общий ход решения проблем, в примерах, и предположения, которыми я руководствовался для оптимизации работы системы.
Сложности, с которыми поначалу сталкивался я сам, были довольно малочисленны, но серьёзны, я узнавал о них из отчетов после краха лоджика, и пытался их решить вслепую, наугад, что не было быстрым, и уж точно не было понятным. В процессе оптимизации работы я пришел к выводу, что нельзя пускать всё на самотек, и что даже достаточно продвинутую в пользовательском отношении OS X не следует оставлять без присмотра, если тебе важны условия комфортной и стабильной работы. Поэтому я взял всё в свои руки и не стал ждать быстрой помощи от купертиновцев, а занялся устранением неполадок самостоятельно.
Все изложенное в той или иной степени проверено и имеет отношение к следующим конфигурациям системы:
iMac 24 – 4 Гб оперативной памяти – Mac OS Snow Leopard 10.6 – Logic Pro 9.1.3
iMac 27 – 4 Гб оперативной памяти – Mac OS Lion 10.7 – Logic Pro 9.1.6
iMac 27 – 12 Гб оперативной памяти – Mac OS Mountain Lion 10.8 – Logic Pro 9.1.7
В поиске решения возникающих проблем, нужно знать, что имеется два их источника: софтварный и хардварный, а также помнить, что огромную помощь в поимке злоумышленника даёт стойкость ошибки, её повторяемость.
Если что-то падает, не работает, лагает и прочее – следует максимально исключить влияние различных устройств, для этого я советую отключить все внешние интерфейсы (миди-контроллеры, звуковые карты и тп) и выяснить, повторятеся ли ошибка, когда они отключены. Также я отключил бы все программы, которые могут помешать – браузеры, плееры, редакторы и прочее ненужное для работы лоджика. Выполнять эти пункты можно в произвольном порядке, кому как удобно, но следует помнить, что отключено, и проверять – повторяется ли ошибка.
Понятно, что ошибка может возникать раз в сутки или раз в месяц, в общем случае потребуется выдержать профилактический период, когда пользоваться лоджиком нужно будет с соблюдением описанных предосторожностей – если ошибку не удается повторить в течении некоторого времени, значит проблема была в чем-то отключенном.
Еще нужно сказать, что есть общий класс проблем OS X, которые точно будут влиять на работу программ. Их много, но сразу что приходит на ум – это права записи, поведение скрытых системных файлов и приоритеты обращений к устройствам и шинам. Помнить об этом полезно, потому как достаточно большое количество ошибок можно устранить с оглядкой на три указанных общих класса недоразумений.
Итак, пугаться не стоит, потому что решение всегда есть, а для вашего удобства привожу понятийный аппарат, который облегчает обнаружение причин:
1. Причина практически всегда описана в «отчете об ошибках» после краха лоджика.
2. Этот отчет является частью более обширного отчета о системных событиях, который называется журнал.
3. Если лоджик не упал, но замедлил свою работу, причина, способствующие этому – с большой вероятностью находится в этом отчете, независимо от того была ли она софтварной (связанной с программным обеспечением) или хардварной (связанной с оборудованием).
4. Если лоджик работал, но выскочило его системное окошко с сообщением об ошибке – причина её тоже есть в этом журнале.
5. Причину можно найти.
6. Причину можно понять.
7. Причину можно простить… и устранить.
И перечень инструментов, необходимых для установления причин и решения проблем:
консоль – /Applications/Utilities/Console.app
терминал – /Applications/Utilities/Terminal.app
мониторинг системы – /Applications/Utilities/Activity Monitor.app
дисковая утилита – /Applications/Utilities/Disk Utility.app
Методология обнаружения ошибок.
Сейчас нам неважно, в первый раз вы столкнулись с ошибкой, или она возникает постоянно.
Если произошел полный крах лоджика, или его зависание и последующее принудительное закрытие пользователем, хорошо бы помнить свои последние действия, возможно они имели значение – это и подгруженный во время воспроизведения плагин, открытие какого-либо окна лоджика или интерфейса инструмента – в общем, лучше помнить что и как вы делали перед крахом.
В отчете об ошибках содержится много информации, и вычленять нужную не всегда удобно именно в нем. К тому же, если лоджик не успел намертво зависнуть, но заметно затормозил, отчета об ошибках может и не появится. Значит, нам лучше воспользоваться консолью, которая помимо прочего представляет собой журнал системных событий.
Открыв программу, вы увидите длинный список всех событий, которые происходят в вашей системе. Он настолько длинный, что искать в нем достаточно тяжело, к тому же в нем выводятся не только ошибки, но и обычные события, которые происходят по ходу дела. Для облегчения поиска имеется возможность отключения показа ненужных событий, тех, в которых вы уверены, что они не являются крахом лоджика. Я, например, отключаю показ событий firewall-а, что делается либо выделением события с его авторством и последующим нажатием на кнопку «игнорировать отправителя», либо в окошке «отправители» внизу слева – где нужно выбрать отключаемого отправителя. Таким образом, переключая видимость/невидимость событий можно облегчить выслеживание нашей причины.
Лоджик свои сообщения отдает под именем Logic Pro и com.apple.logic.pro и для удобства поиска вот строки журнала:
Сообщения о крахе лоджика и создании отчета выглядит так –
сообщение о закрытии вами зависшего лоджика –
Всё, что было прямо до этих строк и будет нашими подозреваемыми. Для поимки настоящего виновника, потребуется немного времени и смекалки – нужно просто отследить часто повторяемые одинаковые сообщения, необязательно лоджика, но если отсылает лоджик, считайте это подарком судьбы – эти ошибки легче отслеживаются, и их причины более понятны. Когда вы обнаружите подозрительное сообщение журнала, копируйте его и гуглите – вероятность нахождения такой проблемы у других пользователей очень велика. Необязательно они будут пользователями лоджика, они могут быть дизайнерами или видеоинженерами, разработчиками игр или еще кем-то, но стандартные сообщения отдаются разными приложениями и чаще всего какое-то решение где-то уже мелькало, а если не решение, то хотя бы намёк на него – графическая ли, например, подсистема глючит, или чтение с диска, и так далее. При небольшом везении вы быстро разберетесь, куда копать.
Опишу теперь свои отловленные ошибки, и решения.
Первое и глобальное столкновение было со всеми известными двумя ошибками лоджика – Error while trying to synchronize Audio and MIDI и System Overload
В журнале удалось отследить причину, догадаться о её возникновении и устранить, что подробно описано вот в этом топике.
Коротко – оказалось, что к появлению этих сообщений привело отсутствие подключения к интернету на моем компьютере (!) отчего лоджик (!) выдавал отчет о перегрузке системы и знаменитую Sample Rate ****** recognized. Заметили несуразность? Я не поверил глазам, но проблема была совершенно точно решена просто подключением компа к виртуальной сети с айпи 0.0.0.0, притом с легкостью возвращалась для проверки и устранялась вновь несколько раз, просто чтобы убедиться, что я не сплю.
Пример 1
В проект, где кроме прочего уже были большие многоканальные сэмплерные инструменты добавил омнисферу (это ладно – ничего не упало и спокойно можно было даже прописывать партии клавишами) – но после перебора её пресетов память омнисферы кончилась, что собственно она и сказала в отдельном окошке, предложив поменять настройки омни-мемори. Это действительно решается настройками самой омнисферы. По слежению за консолью – перед крахом лоджик посылал отчеты в журнал
что продолжалось достаточно долгое время, около 5 минут, что раз 10 сопровождалось проблемами с графическими лагами – мгновенным побелением экрана, некоторым "подвисанием" интерфейса на долю секунды, а затем в журнале несколько раз проскочили
после чего лоджик благополучно упал.
Как ни странно – но оказалось, что WindowServer: отдает ошибку когда переключаешься между рабочими столами. Лоджик у меня на первом рабочем столе висел, а сафари фулскрином на последнем рабочем столе. Удалось достоверно повторить ошибку – при переключениями между столами каждый раз всплывает WindowServer: CGXSetWindowTransformList: Invalid window 0xc6 с разными номерами окон, тоже самое наблюдается при запуске некоторых приложений. Вторую ошибку, которую выдает док – пока не повторил. Видимо она и была критической.
По сути, отключение сафари при работе с лоджиком – нормальное решение. Браузер на движке WebKit (а значит и гугл хром) – плохо сочетается в одновременной работе с Logic Pro. Предположение – скорее всего из-за flash.
Пример 2
В журнале при падении лоджика:
Поиск в гугле подсказал, что это Mail почему-то ругается, ошибка у многих в Lion, по-видимому. По сути сообщения означают, что кто-то куда-то не может произвести запись на диске из-за порушенных прав доступа. Такое бывает, в папках и файлах иногда по некоторым причинам могут нарушиться права, что легко чинится из дисковой утилиты.
Запускаем дисковую утилиту, и выбрав нужный нам диск жмем «Восстановить права доступа»
Кстати, а если у вас внешний жесткий диск? Иногда бывают проблемы чтения с внешних жестких дисков, неважно усб или файрвайр, которые, скорее всего возникают из-за прерываний и глюков шины. Лечится тоже легко:
1. Запустить терминал и напечатать dot_clean (с пробелом на конце)
2. Выбрать в файндере папку, которая создает проблемы (треки обычно обнаруживаются в подпапке внутри проекта, чаще всего это Audio Files) и драг-н-дропнуть эту папку в терминал, только надо дождаться чтобы у курсора появится "+", это означает, что при отпускании мыши после команды будет вписан путь к этой папке, нажать энтер.
Пример 3
В журнале при подвисании лоджика:
Как оказалось, такого рода сообщения могут посылаться не только лоджиком, упоминались иллюстратор, икс-код, файнл и еще несколько приложений.
Выдвигаемые предположения в том, что на компьютере помимо OS X установлена другая операционная система, и она во-первых может производить чтение/запись файлов property list макоси, нарушая, к примеру, у них права доступа, во-вторых, делает что-то, что при запуске макоси требует сканирования спотлайтом заново. Так же еще есть версия, что всё тоже самое могут делать средства разработки, такие как Xcode.
Если виновник – другая система, к которой был подключен диск, например Windows, пусть даже из виртуализатора Parallels, то это лечится командой dot_clean в терминале, как описано в предыдущем примере.
Как восстанавливаются права доступа тоже уже описано.
Про спотлайт можно посоветовать следующее – попробуйте занести папки проектов в блэклист спотлайта (он перестанет их индексировать), потому как некоторые программы, видимо лоджик или плагины, могут создавать где-то временные файлы и папки, куда постоянно обновляют инфу, что ведет к постоянному сканированию спотлайтом и ведет к этой ошибке.
В качестве вывода, напишу общие для всех случаев шаги по оптимизации работы и устранению ошибок.
1. Всё, что вы запускаете на компьютере имеет доступ к оперативной памяти. OS X 10.8 показала себя чуть лучше, чем 10.7 в этом отношении, память расходуется более корректно, хотя определенные неприятности имеются в связи с сыростью версии системы. В частности, лоджик кидает все интерфейсы плагинов в оперативную память, а это png, а иногда tiff – когда плагинов открывалось и крутилось много, лоджик может неудачно взбрыкнуть, помните об этом – failed to allocate 5922816 bytes. Поэтому, желательно держать в близком доступе индикатор использования оперативной памяти, у меня это – стандартный мониторинг системы. При назревании проблем, можно среагировать и перезапустить лоджик до его краха и возможной случайной потери данных.
2. Если вы пользуетесь средствами разработки для Mac OS или операционной системой Windows, установленной отдельно или виртуально на вашем маке, знайте, что это в некоторых случаях может быть причиной нарушений в правах доступа к системным файлы OS X и их целостности, эти файлы могут стать недоступными для записи (лечится дисковой утилитой), либо приобрести новые свойства (лечится dot_clean в терминале).
3. Сведите к минимуму запуск других приложений одновременно с лоджиком, кто бы что ни говорил, но OS X не все задачи может распараллеливать по умолчанию таким образом, что работа будет комфортной – система приоритетов приложений/ресурсов у вас и у макоси, скажем так, не одинаковая. Особенно присваиванием чужих ресурсов страдает Сафари.
4. В случае, когда права доступа к папкам были потёрты сторонними приложениями, а вы в лоджике что-то пытаетесь сделать в его внутреннем браузере, всё может закончится плачевно – спотлайт отработает на 100% и повалит лоджик, если вы попытаетесь из его браузера поискать какой-либо файл в папке с порушенными правами. Костыль, который поможет – добавить папку в блэклист спотлайта, чтобы он её не индексировал. Но делайте это только в крайнем случае, если ничто другое не помогло – ни исправление прав, ни dot_clean в терминале.
UPD от Alf_Zetas:
Windows Regedit даже открыть пустым нельзя - он сразу загружает виндовый реестр, который лежит по строго определенному пути и о существованни в природе каких-либо других файлов он даже не подозревает.
Резюмируя стартопик - эти бесчисленно упоминаемые исправления доступа и удаления испорченных скрытых файлов как бы намекают на ахиллесову пяту мака - хрупкую и ненадежную файловую систему HFS (и ее противоречия с юниксовским фундаментом операционки)
И проблема не в юниксе – он как танк устойчив и надежен, а все проблемы в маковской графической надстройке поверх этого юникса и неродной для него файловой системе.
Часто в HFS что-то рушится и вообще после каждого чиха надо править пермишены
Надо быть нежнее и не напрягать файлы одновременным доступом. А во вторых плисты не обязательно порушились - многие шелудивые производители под видом плистов сохраняют либо активацию, либо маркер первого старта триала. Всяческие клинеры и обслуживание считают єти файлы битыми и удаляют их – и часто после такой чистки у одних плагинов слетает активация, а у просроченных триалов начинается новая жизнь 
*** *** ***
Надеюсь, статья оказалась вам полезной, советы и улучшения приветствуются в комментариях ниже, наравне с вашими примерами побежденных ошибок.
Если у вас возникла ошибка, и вы не знаете как её решить, пишите сюда, будем решать вместе, по мере возможности.
Сложности, с которыми поначалу сталкивался я сам, были довольно малочисленны, но серьёзны, я узнавал о них из отчетов после краха лоджика, и пытался их решить вслепую, наугад, что не было быстрым, и уж точно не было понятным. В процессе оптимизации работы я пришел к выводу, что нельзя пускать всё на самотек, и что даже достаточно продвинутую в пользовательском отношении OS X не следует оставлять без присмотра, если тебе важны условия комфортной и стабильной работы. Поэтому я взял всё в свои руки и не стал ждать быстрой помощи от купертиновцев, а занялся устранением неполадок самостоятельно.
Все изложенное в той или иной степени проверено и имеет отношение к следующим конфигурациям системы:
iMac 24 – 4 Гб оперативной памяти – Mac OS Snow Leopard 10.6 – Logic Pro 9.1.3
iMac 27 – 4 Гб оперативной памяти – Mac OS Lion 10.7 – Logic Pro 9.1.6
iMac 27 – 12 Гб оперативной памяти – Mac OS Mountain Lion 10.8 – Logic Pro 9.1.7
В поиске решения возникающих проблем, нужно знать, что имеется два их источника: софтварный и хардварный, а также помнить, что огромную помощь в поимке злоумышленника даёт стойкость ошибки, её повторяемость.
Если что-то падает, не работает, лагает и прочее – следует максимально исключить влияние различных устройств, для этого я советую отключить все внешние интерфейсы (миди-контроллеры, звуковые карты и тп) и выяснить, повторятеся ли ошибка, когда они отключены. Также я отключил бы все программы, которые могут помешать – браузеры, плееры, редакторы и прочее ненужное для работы лоджика. Выполнять эти пункты можно в произвольном порядке, кому как удобно, но следует помнить, что отключено, и проверять – повторяется ли ошибка.
Понятно, что ошибка может возникать раз в сутки или раз в месяц, в общем случае потребуется выдержать профилактический период, когда пользоваться лоджиком нужно будет с соблюдением описанных предосторожностей – если ошибку не удается повторить в течении некоторого времени, значит проблема была в чем-то отключенном.
Еще нужно сказать, что есть общий класс проблем OS X, которые точно будут влиять на работу программ. Их много, но сразу что приходит на ум – это права записи, поведение скрытых системных файлов и приоритеты обращений к устройствам и шинам. Помнить об этом полезно, потому как достаточно большое количество ошибок можно устранить с оглядкой на три указанных общих класса недоразумений.
Итак, пугаться не стоит, потому что решение всегда есть, а для вашего удобства привожу понятийный аппарат, который облегчает обнаружение причин:
1. Причина практически всегда описана в «отчете об ошибках» после краха лоджика.
2. Этот отчет является частью более обширного отчета о системных событиях, который называется журнал.
3. Если лоджик не упал, но замедлил свою работу, причина, способствующие этому – с большой вероятностью находится в этом отчете, независимо от того была ли она софтварной (связанной с программным обеспечением) или хардварной (связанной с оборудованием).
4. Если лоджик работал, но выскочило его системное окошко с сообщением об ошибке – причина её тоже есть в этом журнале.
5. Причину можно найти.
6. Причину можно понять.
7. Причину можно простить… и устранить.
И перечень инструментов, необходимых для установления причин и решения проблем:
консоль – /Applications/Utilities/Console.app
терминал – /Applications/Utilities/Terminal.app
мониторинг системы – /Applications/Utilities/Activity Monitor.app
дисковая утилита – /Applications/Utilities/Disk Utility.app
Методология обнаружения ошибок.
Сейчас нам неважно, в первый раз вы столкнулись с ошибкой, или она возникает постоянно.
Если произошел полный крах лоджика, или его зависание и последующее принудительное закрытие пользователем, хорошо бы помнить свои последние действия, возможно они имели значение – это и подгруженный во время воспроизведения плагин, открытие какого-либо окна лоджика или интерфейса инструмента – в общем, лучше помнить что и как вы делали перед крахом.
В отчете об ошибках содержится много информации, и вычленять нужную не всегда удобно именно в нем. К тому же, если лоджик не успел намертво зависнуть, но заметно затормозил, отчета об ошибках может и не появится. Значит, нам лучше воспользоваться консолью, которая помимо прочего представляет собой журнал системных событий.
Открыв программу, вы увидите длинный список всех событий, которые происходят в вашей системе. Он настолько длинный, что искать в нем достаточно тяжело, к тому же в нем выводятся не только ошибки, но и обычные события, которые происходят по ходу дела. Для облегчения поиска имеется возможность отключения показа ненужных событий, тех, в которых вы уверены, что они не являются крахом лоджика. Я, например, отключаю показ событий firewall-а, что делается либо выделением события с его авторством и последующим нажатием на кнопку «игнорировать отправителя», либо в окошке «отправители» внизу слева – где нужно выбрать отключаемого отправителя. Таким образом, переключая видимость/невидимость событий можно облегчить выслеживание нашей причины.
Лоджик свои сообщения отдает под именем Logic Pro и com.apple.logic.pro и для удобства поиска вот строки журнала:
Сообщения о крахе лоджика и создании отчета выглядит так –
Код:
[I]com.apple.launchd.peruser.501[257]: ([0x0-0x21b21b].com.apple.logic.pro[2506]) Job appears to have crashed: Abort trap: 6[/I]
[I]ReportCrash[2815]: Saved crash report for Logic Pro[2506] version 9.1.7 (1700.57) to…[/I]
Код:
[I]com.apple.launchd.peruser.501[257]: ([0x0-0x5a05a].com.apple.logic.pro[535]) Exited: Terminated: 15[/I]Всё, что было прямо до этих строк и будет нашими подозреваемыми. Для поимки настоящего виновника, потребуется немного времени и смекалки – нужно просто отследить часто повторяемые одинаковые сообщения, необязательно лоджика, но если отсылает лоджик, считайте это подарком судьбы – эти ошибки легче отслеживаются, и их причины более понятны. Когда вы обнаружите подозрительное сообщение журнала, копируйте его и гуглите – вероятность нахождения такой проблемы у других пользователей очень велика. Необязательно они будут пользователями лоджика, они могут быть дизайнерами или видеоинженерами, разработчиками игр или еще кем-то, но стандартные сообщения отдаются разными приложениями и чаще всего какое-то решение где-то уже мелькало, а если не решение, то хотя бы намёк на него – графическая ли, например, подсистема глючит, или чтение с диска, и так далее. При небольшом везении вы быстро разберетесь, куда копать.
Опишу теперь свои отловленные ошибки, и решения.
Первое и глобальное столкновение было со всеми известными двумя ошибками лоджика – Error while trying to synchronize Audio and MIDI и System Overload
В журнале удалось отследить причину, догадаться о её возникновении и устранить, что подробно описано вот в этом топике.
Коротко – оказалось, что к появлению этих сообщений привело отсутствие подключения к интернету на моем компьютере (!) отчего лоджик (!) выдавал отчет о перегрузке системы и знаменитую Sample Rate ****** recognized. Заметили несуразность? Я не поверил глазам, но проблема была совершенно точно решена просто подключением компа к виртуальной сети с айпи 0.0.0.0, притом с легкостью возвращалась для проверки и устранялась вновь несколько раз, просто чтобы убедиться, что я не сплю.
Пример 1
В проект, где кроме прочего уже были большие многоканальные сэмплерные инструменты добавил омнисферу (это ладно – ничего не упало и спокойно можно было даже прописывать партии клавишами) – но после перебора её пресетов память омнисферы кончилась, что собственно она и сказала в отдельном окошке, предложив поменять настройки омни-мемори. Это действительно решается настройками самой омнисферы. По слежению за консолью – перед крахом лоджик посылал отчеты в журнал
Код:
[I]Logic Pro:__CGPixelAccessDataInitialize: failed to allocate 5922816 bytes[/I]
Код:
[I]WindowServer: CGXSetWindowTransformList: Invalid window 0xc6[/I]
[I]Dock: CGSSetWindowListSystemAlpha: Failed[/I]Как ни странно – но оказалось, что WindowServer: отдает ошибку когда переключаешься между рабочими столами. Лоджик у меня на первом рабочем столе висел, а сафари фулскрином на последнем рабочем столе. Удалось достоверно повторить ошибку – при переключениями между столами каждый раз всплывает WindowServer: CGXSetWindowTransformList: Invalid window 0xc6 с разными номерами окон, тоже самое наблюдается при запуске некоторых приложений. Вторую ошибку, которую выдает док – пока не повторил. Видимо она и была критической.
По сути, отключение сафари при работе с лоджиком – нормальное решение. Браузер на движке WebKit (а значит и гугл хром) – плохо сочетается в одновременной работе с Logic Pro. Предположение – скорее всего из-за flash.
Пример 2
В журнале при падении лоджика:
Код:
[I]kernel[0]: Sandbox: sandboxd(2050) deny mach-lookup com.apple.coresymbolicationd[/I]
[I]sandboxd[2031]: ([2030]) mdworker(2030) deny file-write-data /Users/… … - папка проекта[/I]Запускаем дисковую утилиту, и выбрав нужный нам диск жмем «Восстановить права доступа»
Кстати, а если у вас внешний жесткий диск? Иногда бывают проблемы чтения с внешних жестких дисков, неважно усб или файрвайр, которые, скорее всего возникают из-за прерываний и глюков шины. Лечится тоже легко:
1. Запустить терминал и напечатать dot_clean (с пробелом на конце)
2. Выбрать в файндере папку, которая создает проблемы (треки обычно обнаруживаются в подпапке внутри проекта, чаще всего это Audio Files) и драг-н-дропнуть эту папку в терминал, только надо дождаться чтобы у курсора появится "+", это означает, что при отпускании мыши после команды будет вписан путь к этой папке, нажать энтер.
Пример 3
В журнале при подвисании лоджика:
Код:
[I]Logic Pro[1967]: CFPropertyListCreateFromXMLData(): Old-style plist parser: missing semicolon in dictionary[/I]Выдвигаемые предположения в том, что на компьютере помимо OS X установлена другая операционная система, и она во-первых может производить чтение/запись файлов property list макоси, нарушая, к примеру, у них права доступа, во-вторых, делает что-то, что при запуске макоси требует сканирования спотлайтом заново. Так же еще есть версия, что всё тоже самое могут делать средства разработки, такие как Xcode.
Если виновник – другая система, к которой был подключен диск, например Windows, пусть даже из виртуализатора Parallels, то это лечится командой dot_clean в терминале, как описано в предыдущем примере.
Как восстанавливаются права доступа тоже уже описано.
Про спотлайт можно посоветовать следующее – попробуйте занести папки проектов в блэклист спотлайта (он перестанет их индексировать), потому как некоторые программы, видимо лоджик или плагины, могут создавать где-то временные файлы и папки, куда постоянно обновляют инфу, что ведет к постоянному сканированию спотлайтом и ведет к этой ошибке.
В качестве вывода, напишу общие для всех случаев шаги по оптимизации работы и устранению ошибок.

1. Всё, что вы запускаете на компьютере имеет доступ к оперативной памяти. OS X 10.8 показала себя чуть лучше, чем 10.7 в этом отношении, память расходуется более корректно, хотя определенные неприятности имеются в связи с сыростью версии системы. В частности, лоджик кидает все интерфейсы плагинов в оперативную память, а это png, а иногда tiff – когда плагинов открывалось и крутилось много, лоджик может неудачно взбрыкнуть, помните об этом – failed to allocate 5922816 bytes. Поэтому, желательно держать в близком доступе индикатор использования оперативной памяти, у меня это – стандартный мониторинг системы. При назревании проблем, можно среагировать и перезапустить лоджик до его краха и возможной случайной потери данных.
2. Если вы пользуетесь средствами разработки для Mac OS или операционной системой Windows, установленной отдельно или виртуально на вашем маке, знайте, что это в некоторых случаях может быть причиной нарушений в правах доступа к системным файлы OS X и их целостности, эти файлы могут стать недоступными для записи (лечится дисковой утилитой), либо приобрести новые свойства (лечится dot_clean в терминале).
3. Сведите к минимуму запуск других приложений одновременно с лоджиком, кто бы что ни говорил, но OS X не все задачи может распараллеливать по умолчанию таким образом, что работа будет комфортной – система приоритетов приложений/ресурсов у вас и у макоси, скажем так, не одинаковая. Особенно присваиванием чужих ресурсов страдает Сафари.
4. В случае, когда права доступа к папкам были потёрты сторонними приложениями, а вы в лоджике что-то пытаетесь сделать в его внутреннем браузере, всё может закончится плачевно – спотлайт отработает на 100% и повалит лоджик, если вы попытаетесь из его браузера поискать какой-либо файл в папке с порушенными правами. Костыль, который поможет – добавить папку в блэклист спотлайта, чтобы он её не индексировал. Но делайте это только в крайнем случае, если ничто другое не помогло – ни исправление прав, ни dot_clean в терминале.
UPD от Alf_Zetas:
Windows Regedit даже открыть пустым нельзя - он сразу загружает виндовый реестр, который лежит по строго определенному пути и о существованни в природе каких-либо других файлов он даже не подозревает.
Резюмируя стартопик - эти бесчисленно упоминаемые исправления доступа и удаления испорченных скрытых файлов как бы намекают на ахиллесову пяту мака - хрупкую и ненадежную файловую систему HFS (и ее противоречия с юниксовским фундаментом операционки)
И проблема не в юниксе – он как танк устойчив и надежен, а все проблемы в маковской графической надстройке поверх этого юникса и неродной для него файловой системе.
Часто в HFS что-то рушится и вообще после каждого чиха надо править пермишены
Надо быть нежнее и не напрягать файлы одновременным доступом. А во вторых плисты не обязательно порушились - многие шелудивые производители под видом плистов сохраняют либо активацию, либо маркер первого старта триала. Всяческие клинеры и обслуживание считают єти файлы битыми и удаляют их – и часто после такой чистки у одних плагинов слетает активация, а у просроченных триалов начинается новая жизнь *** *** ***
Надеюсь, статья оказалась вам полезной, советы и улучшения приветствуются в комментариях ниже, наравне с вашими примерами побежденных ошибок.
Если у вас возникла ошибка, и вы не знаете как её решить, пишите сюда, будем решать вместе, по мере возможности.
Последнее редактирование:
estroyAVCDeviceController(AVS::AVCDeviceController*) + 317
