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

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

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

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

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

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

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

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

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

При запуске приложений из Аврора IDE с конфигурацией по умолчанию отладчик gdb не будет работать, так как не будет запущена утилита sailjail, необходимая для отладки.

Для старта sailjail нужно запустить уже установленное приложение на устройстве или на эмуляторе через значок.

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

Запустить приложение в песочнице, используя sailjail или firejail.
- Вариант 1: в разделе Проекты → Запуск поставить галочку Использовать песочницу и запустить проект как обычно.
- Вариант 2: sailjail --dry-run -- PATH.
- Вариант 3 (для отладки c++-кода): sailjail -- PATH.
- Вариант 4 (для отладки qml): firejail c параметрами.
Изменить у приложения конфигурацию по умолчанию в разделе Проекты → Запуск:
- полю Сменить программу на устройстве задать значение /usr/bin/sailjail, предварительно поставив галочку Использовать эту команду напротив поля;
- полю Параметры командной строки задать значение -p <имя_приложения>.desktop /usr/bin/<имя_приложения>.
Данный способ ориентирован на физическое устройство, sailjail не применяется на эмуляторе.

Для отладки qml-кода нужно указать firejail вместо sailjail.
На устройстве потребуется ввести пароль разработчика. Он нужен для того, чтобы дать возможность GDB-серверу подключаться к процессу в песочнице. На эмуляторе пароль не требуется.
Получить pid приложения.

pidof <имя_приложения>

И подключить gdb к процессу, используя pid.

gdb <имя_приложения> -p <pid_приложения>

Ограничения данного способа отладки:

поскольку gdb не запускает процесс, а подключается к нему, то нет возможности отлаживать ошибки запуска программы;
при подключении gdb к процессу, сообщения, которые выводит процесс в консоль методами qDebug и аналогичными, не передаются в окно Аврора IDE;
при запуске приложения в песочнице не работает горячая перезагрузка QML-страниц через QmlLiveBench;
невозможно отладить инициализацию свободных статических переменных.

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

Для отладки процесса запуска программы можно добавить в код вызов метода QThread::sleep(ЧИСЛО_СЕКУНД). Параметр ЧИСЛО_СЕКУНД можно подобрать в зависимости от быстродействия компьютера разработчика: чем медленнее компьютер — тем больше стоит выбрать число.

Пример:

int main(int argc, char *argv[])
{
    QThread::sleep(2);
    QScopedPointer<QGuiApplication> app(SailfishApp::application(argc, argv));
    ...
}

В этом случае gdb сможет гарантированно остановиться на строке, следующей после QThread::sleep(2), что позволит отлаживать процесс запуска программы.

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

Приложение при реальной работе на устройстве запускается в песочнице. Однако во время разработки из 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

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

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

Настроить режим разработчика на устройстве.
Подключиться по SSH к устройству:
```
ssh defaultuser@deviceip
```
Узнать настройки сохранения дампа, считав конфигурацию из файла /proc/sys/kernel/core_pattern. Это можно сделать с помощью команды:
```
sysctl kernel.core_pattern
```
Данная настройка ядра используется ОС. После получения нужного дампа её необходимо будет восстановить, поэтому её следует сохранить. Если этого не сделать, то придётся перезагрузить устройство, чтобы вернуть значение к нужному состоянию.
Настроить сохранение dump-файла, записав следующее значение в файл: core.%u.%e.%p. Оно указывает, что файл дампа должен иметь префикс core, далее через точку должно идти название исполняемого файла, затем через точку его PID. Это можно сделать с помощью команды:
```
devel-su sysctl -w kernel.core_pattern=/srv/shared/{orgName}/{appName}/data/core.%u.%e.%p
```
Запустить приложение обычным образом (через среду разработки или с помощью ярлыка). В случае его падения будет создан дамп в домашнем каталоге пользователя, от имени которого было запущено приложение.
Перенести дамп в сборочное окружение для исследования.
По окончании работ необходимо перезагрузить телефон или вручную восстановить настройку с помощью команды:
```
devel-su sysctl -w kernel.core_pattern='|/usr/sbin/omp-dumper --pid=%p --signal=%s --name=%e'
```