GDB и санитайзеры — бесплатный тест онлайн

Вопрос 1 из 30

Как остановиться только когда `i==997`?

(gdb) break process_item if i == 997

frame 997 watch i==997 continue 997 break loop `break process_item if i == 997`

Вопрос 2 из 30

Чем точка наблюдения данных отличается от обычной точки останова?

(gdb) watch state->count

Точка наблюдения лишь печатает стек после завершения программы и не останавливает её Точка наблюдения всегда работает программно и потому не влияет на скорость выполнения Точка наблюдения применима только к строкам, тогда как точка останова — к числовым переменным Команда `watch` останавливает выполнение при изменении выбранных данных, а обычная точка останова — при достижении адреса кода При каждом изменении данных GDB перезапускает процесс с начала, чтобы восстановить старое значение

Вопрос 3 из 30

Почему `break free` обычно слишком шумен при поиске двойного освобождения?

Функцию `free` вообще нельзя перехватывать отладчиком GDB не способен видеть символы стандартной библиотеки Двойное освобождение не связано с вызовами `free` Он ловит каждое освобождение; лучше условие по адресу или ASan с полными трассами Обычный точка останова срабатывает только один раз за запуск

Вопрос 4 из 30

Как автоматически выполнить команды при точке и продолжить?

(gdb) break process_item
Breakpoint 3 at 0x...
# На каждом попадании нужно печатать n и продолжать выполнение.

Выполнить `next 0`, чтобы GDB повторял последнюю команду на каждом попадании Задать для точки блок `commands`, завершить его `end` и добавить `continue` Объявить в исходнике `typedef` с именем точки останова Использовать условие точки, которое может только остановить, но не печатать значения Создать внешний сценарий командной оболочки, потому что точка останова не поддерживает списки команд

Вопрос 5 из 30

Зачем в GDB использовать `start`, а не ставить случайную точку внутри `main`?

`start` сначала пересобирает программу с символами, а затем запускает новый исполняемый файл `start` запускает программу и останавливает её в начале `main` с готовым контекстом `start` включает AddressSanitizer для первых инструкций, даже если бинарник собран без него Команда удаляет аргументы и переменные окружения, чтобы остановка в `main` была воспроизводимой Перед выполнением первой инструкции команда сохраняет core-файл, пригодный для обратной отладки

Вопрос 6 из 30

Что первым посмотреть после SIGSEGV?

(gdb) bt full
(gdb) frame 2
(gdb) info args
(gdb) info locals

Содержимое Makefile, использованного при последней сборке Размер исходного файла, в котором произошёл сигнал Список файлов рабочего каталога и права на них Только значение `errno`, не меняя текущий кадр стека `backtrace`, затем аргументы и локальные данные текущего кадра

Вопрос 7 из 30

Почему GDB показывает локальную переменную как `<optimized out>`?

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

Вопрос 8 из 30

Как перейти к кадру вызывающей функции?

(gdb) up
(gdb) info locals

`watch caller`, устанавливая наблюдение на имя вызывающей функции `frame 0`, который выбирает самый внутренний текущий кадр `up` либо `frame N`, выбирающие кадр вызывающей функции `stepi -1`, пытаясь выполнить машинную инструкцию назад `finish`, который продолжает программу до возврата из текущей функции

Вопрос 9 из 30

Что может означать бессмысленный стек вызовов после записи за границу локального массива?

char buf[16];
memcpy(buf,input,n); /* n не проверен */

Проблема только в отсутствующих отладочных символах ASLR всегда делает любой стек вызовов бессмысленным Запись могла повредить стек, включая данные кадров и сохранённый адрес возврата Функция `main` была вызвана дважды операционной системой GDB самостоятельно меняет адреса кадров при каждом `backtrace`

Вопрос 10 из 30

Как исследовать содержимое памяти как 16 байтов в hex?

(gdb) p ptr
$1 = (unsigned char *) 0x5555555592a0
(gdb) /* выберите команду просмотра следующих 16 байтов */

`info files ptr`, печатая разделы исполняемого файла `print /s 16`, интерпретируя число как формат строки `disassemble /r ptr,+16`, показывая инструкции, а не произвольные байты данных `bt 16`, выводя шестнадцать кадров стека `x/16bx ptr`: 16 элементов, размер byte, формат hexadecimal

Вопрос 11 из 30

Какой дефект найдёт ASan в коде?

int a[10];
for(int i=0;i<=10;i++) a[i]=i;

Гонку данных между итерациями одного потока Запись в `a[10]`, то есть на один элемент правее массива Только утечку массива `a`, потому что локальная память не освобождается вручную Несоответствие формата `printf`, хотя вывода в программе нет Переполнение значения `i` после последней итерации цикла

Вопрос 12 из 30

Какие части отчёта `heap-use-after-free` наиболее важны для поиска причины?

Цвет, которым терминал выделил сообщение санитайзера Размер исполняемого файла до запуска Стек ошибочного доступа и места выделения и освобождения именно этого блока Только последняя строка внутри реализации `libc` Только идентификатор процесса без адресов и трасс

Вопрос 13 из 30

Почему все объектные файлы ASan-сборки желательно компилировать совместимо?

cc -fsanitize=address -c a.c
cc -fsanitize=address -c b.c
cc -fsanitize=address a.o b.o -o app

Неинструментированные объектные файлы могут выполнять доступы без проверок ASan Без одинаковых флагов все внешние символы исчезают AddressSanitizer превращает язык C в C++ Иначе линковщик всегда отклонит программу ещё до запуска Неинструментированный объектный файл отключает `malloc` во всём процессе

Вопрос 14 из 30

Почему добавление большого случайного запаса к буферу не исправляет ошибку ASan?

Правильное исправление — отключить ASan для этой функции ASan не контролирует объекты больше одной страницы Дополнительная память всегда бесплатна и потому скрывает причину Запас лишь сдвигает границу; нужно исправить расчёт размера и контракт длины Буферы с запасом прямо запрещены стандартом C

Вопрос 15 из 30

Что означает отчёт `stack-use-after-return`?

char *bad(void){ char buf[32]="x"; return buf; }

Оператор `return` был выполнен повторно при восстановлении кадра стека после исключения Переполнена глубина вызовов, но адрес локального буфера остаётся допустимым после возврата Используется адрес локального объекта после завершения функции, которой он принадлежал Функция изменила `errno` перед возвратом, и санитайзер трактует это как доступ к стеку Стековый объект остаётся жив до завершения программы, поэтому отчёт означает ошибку санитайзера

Вопрос 16 из 30

Какой отчёт ожидается для `INT_MAX + 1` при включённой проверке знакового переполнения?

int x=INT_MAX;
printf("%d\n",x+1);

Только предупреждение компоновщика Результат гарантирован 0 Никакого: всегда оборачивание UBSan сообщит о знаковом переполнении ASan сообщит обращение после освобождения памяти

Вопрос 17 из 30

Какое нарушение обнаружит UBSan при выполнении выражения `1u << 32` на реализации с 32-битным `unsigned int`?

uint32_t mask = 1u << 32;

Левый сдвиг всегда выполняет деление на степень двойки, поэтому значение станет нулём Литерал `1u` нельзя использовать как левый операнд сдвига без явного приведения к `uint32_t` Для получения битовой маски необходимо использовать знаковый `int`, а не беззнаковый тип Счётчик равен ширине 32-битного левого операнда; допустимы только значения от 0 до 31 Неопределённое поведение возникает только при сдвиге на ноль, а 32 является допустимым счётчиком

Вопрос 18 из 30

Какой дефект может показать проверка выравнивания?

uint32_t x=*(const uint32_t*)(buf+1);

Повторное закрытие дескриптора, числовое значение которого совпало с адресом буфера Невыровненное чтение через `uint32_t *` Отсутствие нулевого указателя в конце массива аргументов процесса Утечку файлового дескриптора, созданного рядом с буфером в том же кадре стека Взаимную блокировку потоков при одновременном чтении четырёх байтов

Вопрос 19 из 30

Почему `-fno-sanitize-recover=undefined` полезен в проверочной сборке?

cc -fsanitize=undefined -fno-sanitize-recover=undefined test.c

Флаг оставляет диагностику UBSan, но преобразует каждое срабатывание в обычное предупреждение и продолжает тест Флаг отключает только проверки знакового переполнения, сохраняя проверки выравнивания и сдвигов Флаг восстанавливает значение до опасной операции и повторяет выражение в переносимой форме Процесс завершится на первом срабатывании и тест не пройдёт после уже случившегося UB Флаг переключает проверочную сборку с UBSan на ThreadSanitizer при первом нарушении

Вопрос 20 из 30

Обнаруживает ли UBSan все нарушения эффективного типа и строгого псевдонимного доступа?

Нарушения псевдонимного доступа диагностируются компоновщиком, а UBSan подтверждает лишь отсутствие ошибок выравнивания Проверка охватывает доступ через несовместимый тип только для объектов, выровненных по границе `int` Нет, но только потому, что несовместимый доступ становится допустимым после явного приведения указателя Нет, покрытие ограничено; нужны ревизия, предупреждения и корректные способы копирования Да, если собрать программу с `-O0`: тогда UBSan отслеживает тип каждого чтения независимо от выполненного пути

Вопрос 21 из 30

Программа падает на входном файле 20 МБ. Какой следующий шаг даст больше всего информации?

Добавить к файлу ещё 20 МБ нулей Удалить вход, чтобы тест больше не падал Запустить программу без отладочных символов Сохранить вход и уменьшать его, пока падение воспроизводится Сразу переписать весь модуль, не сохраняя вход

Вопрос 22 из 30

Зачем хранить core-файл вместе с точным бинарником и его отладочными символами?

gdb /path/to/exact/app core.1234

GDB извлекает точную сборку и исходники непосредственно из core независимо от окружения Достаточно любого исполняемого файла с тем же именем, даже из другой сборки Отладочные символы используются только компилятором и не участвуют в символизации адресов GDB Адреса из core нужно сопоставлять с тем же бинарником и совместимыми библиотеками, иначе стек и переменные будут неверны Core-файл содержит исходный код и таблицу символов, поэтому отдельный бинарник не нужен

Вопрос 23 из 30

Как проверить гипотезу о переполнении при расчёте длины?

if(n > SIZE_MAX/elem) return ERR;
size_t bytes=n*elem;

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

Вопрос 24 из 30

Почему место аварии может находиться далеко от места, где возникла причина?

Повреждение может оставаться незаметным, но точка аварии всё равно обязана находиться в той же единице трансляции `SIGSEGV` доставляется только при возврате из текущей функции, даже если недопустимая запись произошла раньше Память повреждается раньше, а сбой возникает при позднем использовании испорченных данных Оптимизатор меняет номера строк так, что отладчик всегда останавливается на следующей функции после повреждения Распределитель откладывает все ошибки записи до следующего вызова `malloc` или `free`

Вопрос 25 из 30

Какие длины должны войти в регрессионный тест после исправления ошибки на единицу?

test_len(MAX-1);
test_len(MAX);
test_len(MAX+1);

Ограничиться пустой строкой как представителем всех граничных размеров Проверить границу, значения на единицу меньше и больше и сохранить минимальный воспроизводимый пример Проверить исходную длину сбоя и несколько произвольных далёких значений Проверить выпускную сборку без инструментирования, чтобы расположение памяти не менялось Запустить большой набор случайных размеров без отдельного внимания к соседям границы

Вопрос 26 из 30

Почему core-файл нельзя без проверки прикладывать к публичной задаче?

Снимок памяти способен содержать токены, ключи, пароли, пользовательские данные и буферы При завершении по сигналу core содержит только заголовок без адресного пространства Файл содержит номера сигналов и имена функций, но не байты памяти процесса Core пригоден лишь на машине, где возник сбой, даже при совпадении бинарника и библиотек Из данных приложения в core попадают адреса кода, но не содержимое стека и кучи

Вопрос 27 из 30

Почему гонка данных может исчезнуть при запуске под GDB?

Отключение ASLR задаёт порядок операций памяти и исключает любые межпоточные гонки Под GDB программа выполняет только главный поток, если явно не выбрать другой командой `thread` Остановки и пошаговое выполнение меняют расписание и временные окна потоков GDB исправляет операции блокировки при загрузке символов и тем самым устраняет гонку Отладчик делает все доступы к переменным последовательными атомарными операциями

Вопрос 28 из 30

Можно ли считать проект безопасным после одного чистого прогона ASan?

Да, один чистый прогон ASan доказывает полную безопасность Нет: не все пути выполнены и ASan не покрывает все классы ошибок Нет только для C++; для C одного прогона достаточно ASan проверяет лишь синтаксис, но не память Да, если в тесте было не меньше ста вопросов

Вопрос 29 из 30

Как уменьшить риск утечки секрета через диагностический журнал?

Полностью отключить сообщения об ошибках Удалить временные метки, оставив секреты без изменений Писать только безопасные метаданные, маскируя значения и доступ Печатать весь объект в шестнадцатеричном виде Перенести вывод из файла в `stdout`

Вопрос 30 из 30

Почему диагностическая сборка должна быть достаточно близка к рабочей?

cc -### ...
/* сравниваются диагностическая и рабочая команды сборки */

Отладочный и рабочий бинарники обязаны всегда совпадать побайтно Флаг `-g` меняет правила языка C Различия в макросах, ABI и оптимизации могут убрать или добавить исследуемое поведение Санитайзеры требуют только `-O3` и не работают с другими уровнями Рабочую сборку принципиально нельзя исследовать отладчиком