Lldb rpc server что это

Что такое LLDB RPC сервер? Когда он падает в Xcode? Почему он падает?

сервер LLDB RPC разбился. Журнал сбоев находится в ~/Library/Logs / DiagnosticReports и имеет префикс ‘lldb-rpc-server’. Пожалуйста, напишите ошибку и прикрепите последний журнал сбоев.

автор: shallowThought

5 ответов

в моем случае сервер LLDB RPC последовательно разбивался каждый раз, когда я запускал свое приложение, даже после очистки папки сборки и удаления и переустановки Xcode (версия 8.3.3 (8E3004b)) полностью.

оказалось, что, по-видимому, LLDB возражал против точки останова, которую я установил, просто переместив эту точку останова линией, решил проблему.

автор: Stefan

у меня была та же проблема и исправлена после удаления некоторых точек останова. Не знаю, почему это произошло, но, по крайней мере, вы можете удалить точки останова и использовать NSLog() или print() Если вы находитесь в Swift и отлаживаете с помощью них. Удачи!

автор: Boris Nikolić

в моем случае: я недавно обновился до версии Xcode 9.3 (9E145), и Xcode выполняется до строки с точкой останова, затем я набираю «po XXX», и он покажет то же сообщение. Я пытаюсь удалить следующие файлы

~/Library/Preferences/com.apple.dt.Xcode.plist ~/Library/Caches/com.apple.dt.Xcode 

и он решается. не знаю почему, но попробовать стоит.

Не забудьте сделать резервную копию этих файлов для восстановления в случае возникновения любой непредвиденной ситуации.

автор: kidnapper

в моем случае. Я также использую SQLite.swift для создания базы данных. Сбой произошел, когда я попытался изменить тип данных столбца существующей таблицы в коде(что было неправильно), затем вставил кортеж с новым типом данных, а затем попытался распечатать весь кортеж.

решение: удалить .файл базы данных sqlite3 у вас есть или удалить таблицу с типом данных конфликта и воссоздать их все.

Как мы ускоряли работу отладчика Swift

Привет! Меня зовут Александр Скворцов, я работаю в команде Яндекс.Браузера для iOS. Это очень большой проект, который насчитывает около тысячи clang-модулей и примерно 600 Swift-модулей. Наверное, из-за таких масштабов мы чаще других наталкиваемся на проблемы инструментов разработки, например, находим критические ошибки в компиляторе, неработающую подсветку и автодополнение. Это бывает неприятно, но жить можно.

Самая серьёзная проблема возникла с отладкой. В худшем случае с момента запуска до остановки в отладчике на точке входа в приложение проходило больше 20 минут. И это на свежем MacBook Pro 16! С таким «быстродействием» инструментов разработки невозможно эффективно развивать проект, поэтому мы решили разобраться в причинах и поискать возможные решения. В результате получилось не только снять остроту проблемы у себя, но и внести правки в код отладчика Swift — со временем описанные в статье неприятности перестанут беспокоить всех пользователей Xcode. А теперь расскажу подробнее, как это было.

История уходит корнями в появление замечательного языка Swift, задуманного как замена Objective-C для разработки в экосистеме Apple. Много воды утекло с момента выхода первой версии: значительно изменился синтаксис, расширились возможности стандартной библиотеки, добавлено много синтаксического сахара, облегчающего жизнь, появился стабильный ABI. Но кое-что (надёжность инструментов разработки) сохранилось практически в первозданном виде…

Механизмы интеграции Swift с кодом на других языках

Небольшой, но важный спойлер: во время диагностики мы выяснили, что основную часть времени при запуске занимает компиляция clang-модулей, которые требуются для интерпретации выражений на Swift в консоли отладчика. Чтобы описанные ниже решения стали понятнее, следует сказать пару слов о механизмах интеграции Swift с кодом, написанным на других языках. Если вы хорошо знакомы с этой темой, можете смело переходить к следующей части статьи.

Bridging Header

Тривиальный способ, он не требует предусловий от импортируемого кода. Bridging Header — привычный для разработчиков на Objective-C заголовочный файл, в котором с помощью директивы #import перечисляется список заголовков, содержимое которых нужно использовать в коде на Swift. Однако, у этого способа есть существенный недостаток: Swift-модуль, в котором используется Bridging Header, нельзя импортировать в другой Swift-модуль (на самом деле можно, если вы компилируете без Xcode, но цена этого — сложнорешаемые проблемы со сборкой и отладкой). Поэтому он подходит только для модулей, содержащих точку входа в приложение, а мы из-за этого ограничения полностью отказались от Bridging Header-ов.

Clang-модули

Альтернативным способом интеграции с C и Objective-C являются clang-модули. Это более универсальный подход, так как, в отличие от Bridging Header-ов, clang-модули не накладывают ограничений на Swift-код. Что важно, ведь Swift уже стал основным языком разработки под iOS.

Для оптимизации по времени при компиляции Swift для clang-модулей используется аналог предварительно откомпилированных заголовков: создаётся неявно управляемый компилятором кеш из предварительно откомпилированных модулей, который позволяет не интерпретировать clang-модуль заново каждый раз при обработке директивы import в Swift-коде. Компиляция clang-модуля занимает нетривиальное количество времени (до нескольких секунд), поэтому при большом количестве модулей в проекте наполнение кеша бывает довольно долгим. Сейчас (в версии Swift 5.3) единственная настройка поведения кеша модулей — путь к нему, но уже анонсирован механизм явной сборки.

В поисках проблемы

К счастью, в сборке lldb , которая поставляется в составе Xcode, есть названия символов, поэтому процесс lldb-rpc-server можно информативно профилировать. В результате профилировки, как я уже писал выше, выяснилось, что основную часть времени при запуске занимает как раз компиляция clang-модулей:

14.15 min 100.0% 0 s lldb-rpc-server (42247) 14.15 min 99.9% 0 s thread_start 14.15 min 99.9% 0 s _pthread_start 12.99 min 91.7% 0 s threadFuncSync(void*) 12.99 min 91.7% 0 s RunSafelyOnThread_Dispatch(void*) 12.99 min 91.7% 0 s llvm::CrashRecoveryContext::RunSafely(llvm::function_ref) 12.99 min 91.7% 0 s void llvm::function_ref::callback_fn(long)

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

Но нас всё ещё не устраивает время запуска отладчика, поэтому копаем дальше. Включаем логи отладчика по инструкции и смотрим на них в надежде увидеть хоть что-то необычное… А вот и результат — натыкаемся на очень интересную строчку:

Extra clang arguments : (28814 items)

После неё идёт длинный список из аргументов, состоящий в основном из флагов -I , -F и -fmodule-map-file= , значения которых повторяются. Такая находка наводит на мысль о возможной неэффективности процесса сборки clang-модулей, который и занимает львиную долю времени запуска отладчика. Дело за малым — разобраться, насколько это предположение близко к истине.

Об особенностях работы отладчика Swift

Прежде чем приступить к проверке гипотезы, следует немного углубиться в детали работы отладчика Swift. Формат DWARF, использующийся для C, Objective-C и C++, не позволяет записать всю необходимую для вычисления выражений информацию. Поэтому частично она хранится в файлах swiftmodule , которые являются одним из артефактов сборки Swift-кода. Абсолютный путь до каждого swiftmodule записывается линковщиком в исполняемый файл, чтобы отладчик мог читать из него нужную информацию.

Интересующая нас часть отладочной информации — список аргументов clang. Он формируется на основе параметров компилятора Swift, передаваемых при сборке модуля. Найденная аномалия заключается в дублировании аргументов clang, поэтому важно убедиться, что оно происходит не по нашей вине — такое дублирование может происходить в том числе из-за неправильной работы системы сборки. Смотрим подробный отчёт вызываемых при компиляции команд и видим, что значения параметров -I , -F и -fmodule-map-file= уникальны внутри каждого вызова компилятора, поэтому переходим к изучению отладчика.

We need to go deeper

Первым делом скачиваем исходный код и находим место, в котором печатается интересующая нас строка лога:

 swift::ClangImporterOptions &clang_importer_options = GetClangImporterOptions(); log->Printf(" Extra clang arguments : (%llu items)", (unsigned long long)clang_importer_options.ExtraArgs.size()); for (std::string &extra_arg : clang_importer_options.ExtraArgs) < log->Printf(" %s", extra_arg.c_str()); >

Путём нехитрого анализа окружающего кода выясняем, что дублирующиеся аргументы добавляются в этом методе, который в цикле вызывается вот отсюда:

 std::function process_one_module = [&](ModuleSP &&module_sp) < SwiftASTContext *ast_context = llvm::dyn_cast_or_null(&*type_system_or_err); if (ast_context && !ast_context->HasErrors()) < swift_ast_sp->AddExtraClangArgs(ast_context->GetClangArguments()); > > >; for (size_t mi = 0; mi != num_images; ++mi)

В итерациях цикла используются данные, прочитанные из файлов swiftmodule , механизм работы которых мы обсудили в предыдущей части.

Как видно из кода, при формировании конечного списка аргументы, прочитанные из swiftmodule , предварительно обрабатываются:

• отбрасывается флаг -Werror , чтобы не вызывать лишних ошибок при интерпретации выражений в консоли отладчика;
• относительные пути дополняются до абсолютных;
• и, наконец, устраняютсядублирующиеопределения макросов.

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

В этом плане есть серьёзные изъяны:

• во-первых, чтобы проверить гипотезу путём внесения изменений в код отладчика, нужно его скачать и скомпилировать, что займёт немало времени и места на SSD;
• во-вторых, даже если наша версия подтвердится, применить результаты на практике получится очень нескоро из-за длинного релизного цикла инструментов разработки.

Что ж, нам ничего не остаётся, кроме как искать обходной путь.

Обходной путь

Для интерпретации выражений в консоли отладчика создаётся некий контекст компиляции Swift. Его параметры должны разрешать использование любых типов или функций из любого модуля в исполняемом файле. Как мы уже выяснили, информация о clang-модулях попадает в контекст через пути поиска, прочитанные из файлов swiftmodule , которые, в свою очередь, добавляются в исполняемый файл линковщиком. Фрагмент аргументов линковщика выглядит так:

-add_ast_path path/to/swift/module1.swiftmodule -add_ast_path path/to/swift/module2.swiftmodule . -add_ast_path path/to/swift/moduleN.swiftmodule

Мы хотим избежать конкатенации путей поиска из всех N файлов swiftmodule , которая приводит к дублированию и неконтролируемому росту списка аргументов clang в контексте компиляции Swift. Для этого можно попробовать передать линковщику только один swiftmodule . Здесь нас поджидает небольшая проблема: хочется не только ускорить запуск отладчика, но и не потерять его работоспособность.

Значит, единственный swiftmodule должен предоставлять объём отладочной информации, эквивалентный тому, что даёт полный набор. Проанализировав код отладчика, обнаруживаем, что из swiftmodule берутся только аргументы clang, поэтому сформировать нужный нам «супермодуль» не составит труда — он должен состоять из одного файла, где будут перечислены директивы import каждого clang-модуля, входящего в исполняемый файл:

import ClangModule1 import ClangModule2 . import ClangModuleN

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

Как мы уже знаем, внутри отдельно взятого swiftmodule список аргументов clang уникален, поэтому заменяем наши многочисленные -add_ast_path на единственный -add_ast_path path/to/swift/supermodule.swiftmodule , и наблюдаем искомый результат:

Extra clang arguments : (962 items)

Новая профилировка запуска отладчика показывает, что гипотеза о неэффективности компиляции clang-модулей подтвердилась:

3.99 min 100.0% 0 s lldb-rpc-server (44423) 3.99 min 99.9% 0 s thread_start 3.99 min 99.9% 0 s _pthread_start 2.96 min 74.3% 0 s threadFuncSync(void*) 2.96 min 74.3% 0 s RunSafelyOnThread_Dispatch(void*) 2.96 min 74.3% 0 s llvm::CrashRecoveryContext::RunSafely(llvm::function_ref) 2.96 min 74.3% 0 s void llvm::function_ref::callback_fn(long)

При этом отладчик остаётся исправным, а время старта сокращается примерно до 4 минут! Конечно, это всё ещё невыносимо долго, но уже намного лучше, чем было раньше, поэтому создаём пул-реквест и радуем коллег.

Вместо заключения

Описанный способ невозможно реализовать, если вы используете встроенный xcodebuild для сборки проекта. К счастью, это не наш случай — размеры проекта не позволяют ограничиться стандартными инструментами. Мы работаем с нестандартным тулчейном, основанным на gn, благодаря которому удалось относительно легко провернуть манёвр с «отладочным» swiftmodule .

Решив проблему локально, мы не забыли внести правки (раз, два) в код отладчика. Со временем дублирование аргументов clang останется в прошлом для всех пользователей Xcode. Однако наша война ещё не окончена — 4 минуты на запуск отладчика (напомню, что это худший случай: после очистки DerivedData и перезапуска Xcode) нас не устраивают. А значит, возможно не менее увлекательное продолжение истории. Stay tuned!

LLDB RPC Server Crashed (Xcode 12)

You’re now watching this thread. If you’ve opted in to email or web notifications, you’ll be notified when there’s activity. Click again to stop watching or visit your profile to manage watched threads and notifications.

You’ve stopped watching this thread and will no longer receive emails or web notifications when there’s activity. Click again to start watching.

We have some developers on our team experiencing a crash while trying to debug.

Message from debugger: The LLDB RPC server has crashed. The crash log is located in ~/Library/Logs/DiagnosticReports and has a prefix ‘lldb-rpc-server’. Please file a bug and attach the most recent crash log.

Code Block
 
Fatal error: Invalid position SourceEditorPosition: line: 244, col: 38 with line length 26 : file /Library/Caches/com.apple.xbs/Sources/SourceEditor/SourceEditor-17136/SourceEditor/SourceEditor/CoreEditor/Model/SourceEditorDataSource.swift, line 2710

This is happening with breakpoints in specific spots in our mostly C++ codebase. It is happening in Xcode 12.0.1 and did not happen in the same version of Xcode in our branch without the Widget Extension added. Is there anything we can do? We’ve reported it with Apple Feedback and heard nothing back. We’re going to try to reproduce it on Xcode 12.1.1 RC.

Xcode 14.2+: lldb-rpc-server has crashed.

You’re now watching this thread. If you’ve opted in to email or web notifications, you’ll be notified when there’s activity. Click again to stop watching or visit your profile to manage watched threads and notifications.

You’ve stopped watching this thread and will no longer receive emails or web notifications when there’s activity. Click again to start watching.

I don’t know when this started but it’s basically brought my development to a standstill. I know it worked fine in macOS 13.2.1, though I didn’t try Xcode 14.3 RC 2 in 13.2.1.

Basically, Xcode 14.3 RC 2 (14E222b) and also Xcode 14.2 (14C18) (which had been stable up till now) are both unable to launch the app in debug mode. As soon as the launched/debugged app finally starts, the following is printed to Xcode’s console:

Message from debugger: The LLDB RPC server has crashed. You may need to manually terminate your process. The crash log is located in ~/Library/Logs/DiagnosticReports and has a prefix 'lldb-rpc-server'. Please file a bug and attach the most recent crash log. 

There seems to be an infinite loop in thread 6:

Thread 6 Crashed:: <lldb.process.internal-state(pid=30877)> 0 LLDB 0x12030cfb4 ParseTrieEntries(. ) + 20 1 LLDB 0x12030d653 ParseTrieEntries(. ) + 1715 

After I initially encountered this issue in Xcode 14.3 RC 2 (14E222b) with my business project, I tried creating a new Cocoa app using Xibs and Objective-C and still encountered the problem in that project. I’ve cleaned out the build folders, etc. but that made no difference. I opened both my business project and a new project in Xcode 14.2 (14C18) but saw no difference (it still crashes). I also tried in a new user account using both versions of Xcode but they both crash.

Could having Python 3.10 and 3.11 installed through MacPorts anything to do with it (I noticed Python 3.9 in the binary images, but I’m not sure).