Является ли хорошей практикой использование Stack Trace библотек в дебаг сборке?

Question

[floppa322]

Всем привет

Является ли хорошей практикой использование инструментов вроде Backward-cpp во время разработки приложений ? И имеют ли какие-либо неочевидные подводные камни ? (понятно, что имеется в виду компиляция с выключенным флагом оптимизации)

Также, в частности Backward-cpp может навешивать колбэки на разные системные сигналы типа необработанного исключения или сегфолта

Использование на примере макроса assert'а:

// smartAssert.h

void smartAssert(bool expression)
{
    if (expression)
        return;

    using namespace backward;

    StackTrace stackTrace;
    stackTrace.load_here(32);

    Printer printer;
    printer.object = true;
    printer.color_mode = ColorMode::always;
    printer.address = true;

    printer.print(stackTrace, stdout);
}

// config.h

#ifdef DEBUG
#   include "external/backward/backward.cpp"
#endif

#ifdef DEBUG
#   include "SmartAssert.h"
#   define SMART_ASSERT(expression) do { smartAssert(expression); } while (0)
#else
#  define SMART_ASSERT(expression) do {} while (0)
#endif

Answer 1

[Wataru]

Это нормальная практика. Например, ваш браузер скорее всего именно таким инструментом пользуется (если он на хромиуме основан).

Comments

[floppa322]

Хорошо

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

Ну то есть, есть совсем очевидные, вроде того, что с -02 стек трейс будет некорректным, но может быть есть ещё какие-то менее очевидные ?

[Евгений Шатунов]

floppa322, подводные камни - это возможность полной декомпиляции твоей программы по ее отладочным меткам. В наши дни эта проблема решается обрезанием отладочной информации в процессе релиза для пользователей. В результате пользователи при падении видят только отчет со стеком вызовов и все. Это действие - джентельменский минимум уважающего себя производителя ПО.

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

Проблем с регистрацией событий нет. Это - штатный функционал стандартной библиотеки. Сегодня довольно много инструментов (вроде GeForce Experience, Logitech G Hub или Realtek Sonic, т.е. вещи все знакомые) для своей работы используют куда более изощренные методы встраивания в исполняемый код процессов пользователя.

[floppa322]

Евгений Шатунов,

подводные камни - это возможность полной декомпиляции твоей программы по ее отладочным меткам. В наши дни эта проблема решается обрезанием отладочной информации в процессе релиза для пользователей. В результате пользователи при падении видят только отчет со стеком вызовов и все. Это действие - джентельменский минимум уважающего себя производителя ПО.

Извиняюсь за глупый вопрос, но откуда у пользователя (то есть владельца релизной сборки) возьмётся корректный (как в исходной программе) стек вызовов ? Ведь в релизная сборка компилируется со включённой оптимизацией, а значит и стек вызовов с вероятностью 99% не будет совпадать с исходной программой

Ну то есть сам стек вызовов-то будет, но пользы от него будет 0

[floppa322]

Евгений Шатунов, стало быть, если приложение чисто серверное, то бояться декомпиляции не стоит ?

[floppa322]

Евгений Шатунов,

а, ещё вопрос: на практике в релизных сборках устанавливают ли колбэки на системные исключения, вроде сегфолта, с последующим выводом стека вызовов ? понятно, что с -o2 он будет менее информативен, но тем не менее

и не влияет же на производительность приложения само наличие колбэка на системное исключение, с телом, логирующим стек вызовов ?

[Евгений Шатунов]

floppa322,

Извиняюсь за глупый вопрос, но откуда у пользователя возьмётся корректный стек вызовов?

Вот эта самая Backward-cpp и ей подобные выдачу коллстека и сделают корректной. Современная инструментация отладки позволяет опознать фрагменты встроенного кода и правильно оформить коллстек для выдачи.

если приложение чисто серверное, то бояться декомпиляции не стоит?

Многие погорельцы именно так и думали. Но дело в том, что и серверное ПО тоже можно заполучить себе в руки после взлома сервера. Нет, если ПО чисто серверное, его ровно так же нужно защищать, как будто оно уже отдано пользователю.

на практике в релизных сборках устанавливают ли колбэки на системные исключения, вроде сегфолта, с последующим выводом стека вызовов?

На практике уважающее себя ПО в руках пользователя работает под присмотром брокера статистики и отладки. Качественного ПО в наши дни нет. Всякая программа у пользователя упадет. Важность в том, чтобы падение это донести до разработчиков в максимально информативном виде.
Брокер ведет программу до ее падения. В момент падения брокер перехватывает управление на себя, формирует крашдамп, формирует отправку на сервера разработчиков, уведомляет пользователя о том, что программа упала и разработчики уже в курсе, после чего мирно кладет программу до нового запуска.
И как же иначе брокер, будучи внутри процесса ПО, может все это выполнить, как не через обработчики сигналов и прерываний? А никак.
И на производительности конкретно установка обработчиков тоже не сказывается.

[floppa322]

Евгений Шатунов,

Извиняюсь за глупый вопрос, но откуда у пользователя возьмётся корректный стек вызовов?

Вот эта самая Backward-cpp и ей подобные выдачу коллстека и сделают корректной. Современная инструментация отладки позволяет опознать фрагменты встроенного кода и правильно оформить коллстек для выдачи.

Проверял с -02 дамп стек трейса, в частности, Backward-cpp не восстановил именно исходный, до оптимизаций вид стека вызовов, но может быть я не до конца изучил его api, хотя оно достаточно простое и прямолинейное

И на производительности конкретно установка обработчиков тоже не сказывается.

я почему поинтересовался, потому что, например, само наличие блоков try/catch, насколько мне известно, немного замедляет приложение (не в момент пробрасывания исключения, а вообще)

[Евгений Шатунов]

floppa322,

само наличие блоков try/catch, насколько мне известно, немного замедляет приложение

А про это много кто слышал и мало кто видел. И еще меньше тех, кому это нужно. Да и нужно это только на платформе x86. Т.е. нужно было, но не нужно уже.
Платформа x64 всегда и по умолчанию использует вектора прерываний для обработки исключений, буквально в независимости от настроек сборки проекта.

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

[floppa322]

Евгений Шатунов, ок, спасибо за информацию )