Выявление ошибок в работе с памятью в C и C++: Сравниваем Sanitizers и Valgrind

[Apoheliy]

По-моему, очень сильно притянутые за уши примеры кода.

Эта статья мало того, что автоматически переведённая (порадовал термин "Поймал" в табличке), так и примеры приведены странные.

Например, в статье приводится такой код:

#include <stdlib.h>
int main() {
  char *p = malloc(16);
  char *p2 = malloc(16);
  p[24] = 1; // выход за пределы буфера, в p всего 16 байт
  free(p2); // free(): некорректный указатель
  free(p);
  return 0;
}

И утверждается, что glibc такое ловит и это хорошо. Ругается на освобождение p2, так как он некорректный. А чем, собственно, p2 оказался плох? Из примеров это непонятно, и glibc выдаёт какую-то странную диагностику.

Хорошо, попробуем разобраться. И тут выясняется, что если, например p[24] заменить на p[23], то всё отлично будет выполняться: glibc ругаться не будет, всё выполняется без ошибок. Хотя выход за пределы буфера остаётся.

А в сухом остатке: в коде подобран такой параметр, чтобы оно ловилось. То, что для других ошибочных ситуация оно не работает (которых сильно больше) - "Ну ведь это не важно, да?".

Прим: магическое число 24, подозреваю, связано с описателями блоков памяти: после 16 байт валидной памяти выделяется ещё 8 байт, которые можно портить безнаказанно (не падаем на "лёгком" переполнении), а вот дальше - уже проблемы.

[kekoz]

У Valgrind есть один весомый недостаток, “незамеченный” в статье — он чертовски зависит от среды исполнения. Буквально одна цифра в минорной части версии ядра — и нужно искать соответствующий Valgrind.

[AndreyAf]

можно подробнее? версия ядра чего именно?