Отладка проекта

Отладку проекта можно выполнить несколькими способами.

Проект в целом можно отладить с помощью инструмента gdb. При этом необходимо учитывать, что для ОС Аврора 4 и выше изоляция приложений накладывает ограничения на отладчик.

QML-код можно изменять без перезапуска приложения. Для этого следует использовать QmlLiveBench.

Для QML и C++-частей приложения доступно профилирование.

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

• Отладка приложений с изоляцией
• Отладка приложений в песочнице
• Дамп приложения

Отладка приложений с изоляцией

Отладчик gdb можно подключить к приложению по номеру процесса, например, через консоль или переконфигурацию gdb из Аврора IDE и двустороннюю передачу данных между gdb и Аврора IDE.

Отладку можно выполнить при помощи запуска проекта в песочнице. Начиная с Аврора SDK 5.2, в разделе Проекты → Запуск данная галочка выставлена по умолчанию:

Приложения в Аврора SDK 5.2 запускаются с использованием runtime-manager, поэтому для запуска приложений на устройствах с ОС Аврора 5.1 и ниже следует выставить галочку Режим совместимости:

Отладка приложений в песочнице

Приложение при реальной работе на устройстве запускается в песочнице. Однако во время разработки из IDE приложение по умолчанию запускается вне песочницы.

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

Для отладки в песочнице существует утилита runtime-manager-tool, которая поставляется в одноимённом пакете. Также её функциональность доступна и через D-Bus, поэтому в инструкции ниже будут приводиться и команды D-Bus для случаев, когда невозможно установить утилиту.

Команда для передачи переменных среды:

runtime-manager-tool Control startDebug com.example.app -e "QT_LOGGING_RULES=*.debug=true"

Аналогичная команда для D-Bus:

gdbus call -e -d ru.omp.RuntimeManager -o /ru/omp/RuntimeManager/Control1 \
    -m ru.omp.RuntimeManager.Control1.StartDebug \
    com.example.app "{'environment':<['QT_LOGGING_RULES=*.debug=true']>}"

Команда для запуска со strace:

runtime-manager-tool Control startDebug com.example.app \
    --wrapper "strace -f" -j,--allow-debuggers --stderr $(tty)

Также можно запускать Valgrind и другие неинтерактивные обёртки.

Аналогичная команда для D-Bus:

gdbus call -e -d ru.omp.RuntimeManager -o /ru/omp/RuntimeManager/Control1 \
    -m ru.omp.RuntimeManager.Control1.StartDebug \
    com.example.app \
    "{'applicationWrapper':<['strace','-f']>, 'firejailParams':<['--allow-debuggers']>, 'stderrFile':<'$(tty)'>}"

Если требуется отправить вывод команды в файл, то надо указывать его имя вместо $(tty), например, strace.log. Если полный путь не будет указан, то файл будет создаваться в домашнем каталоге.

Команда для отладки с gdb:

runtime-manager-tool Control startDebug com.example.app \
    --wrapper "gdbserver 127.0.0.1:10050" \
    -j,--allow-debuggers \
    -j,--protocol=inet \
    -j,--ignore="net none" \
    -j,--private-bin=bash,sh,busybox \
    -j,--noblacklist=/bin/busybox \
    --stderr $(tty) --stdout $(tty)

Аналогичная команда для D-Bus:

gdbus call -e -d ru.omp.RuntimeManager -o /ru/omp/RuntimeManager/Control1 \
    -m ru.omp.RuntimeManager.Control1.StartDebug \
    com.example.app \
    "{'applicationWrapper':<['gdbserver', '127.0.0.1:10050']>, \
     'firejailParams':<['--allow-debuggers', '--protocol=inet', \
                        '--ignore=net none', '--private-bin=bash,sh,busybox', \
                        '--noblacklist=/bin/busybox']>, \
     'stderrFile':<'$(tty)'>, 'stdoutFile':<'$(tty)'>}"

Затем на компьютере разработчика следует выполнить команду:

gdb-multiarch

И на промпте gdb выполнить:

target remote 192.168.2.15:10050

Дамп приложения

На этапе разработки дамп приложения можно получить следующим образом:

1. Настроить режим разработчика на устройстве.

2. Подключиться по SSH к устройству:

   ssh defaultuser@deviceip
   

3. Узнать настройки сохранения дампа, считав конфигурацию из файла /proc/sys/kernel/core_pattern. Это можно сделать с помощью команды:

   sysctl kernel.core_pattern
   

   Данная настройка ядра используется ОС. После получения нужного дампа её необходимо будет восстановить, поэтому её следует сохранить. Если этого не сделать, то придётся перезагрузить устройство, чтобы вернуть значение к нужному состоянию.

4. Настроить сохранение dump-файла, записав следующее значение в файл: core.%u.%e.%p. Оно указывает, что файл дампа должен иметь префикс core, далее через точку должно идти название исполняемого файла, затем через точку его PID. Это можно сделать с помощью команды:

   devel-su sysctl -w kernel.core_pattern=/srv/shared/{orgName}/{appName}/data/core.%u.%e.%p
   

5. Запустить приложение обычным образом (через среду разработки или с помощью ярлыка). В случае его падения будет создан дамп в домашнем каталоге пользователя, от имени которого было запущено приложение.

6. Перенести дамп в сборочное окружение для исследования.

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

   devel-su sysctl -w kernel.core_pattern='|/usr/sbin/omp-dumper --pid=%p --signal=%s --name=%e'