История изменений

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

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

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

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

Memcheck такое поймает.

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

У нас свобода вероисповедания, так что можешь верить во что хочешь. Я оспаривал утверждение о том, что Valgrind «выдает очень много ошибок, которые не ошибки, потому что программа многопоточна и имеет асинхронный ввод-вывод». Это утверждение ложно.

valgrind и так всё найдёт

Где-то кто-то утверждал, что Valgrind находит прямо всё? Это очевидно невозможно.

где очень пытались делать вид, что проблемы не существует,

Это безосновательные спекуляции.

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

Я об этом уже писал. Если у тебя странные указатели, то финальном отчёте (который ещё нужно включить) память попадёт в список потерянной, а не ещё доступной. В любом случае, если ты хочешь проверять утечки памяти утилитами, нужно как минимум иметь режим работы программы, в котором она тщательно освобождает всю выделенную память штатными методами, а не «завершился-освободился».

Удивительно, что во времена, когда программы часто работают месяцами, тебя вообще волнует, что там, в этом финальном отчёте Memcheck.

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

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

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

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

Memcheck такое поймает.

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

У нас свобода вероисповедания, так что можешь верить во что хочешь. Я оспаривал утверждение о том, что Valgrind «выдает очень много ошибок, которые не ошибки, потому что программа многопоточна и имеет асинхронный ввод-вывод». Это утверждение ложно.

valgrind и так всё найдёт

Где-то кто-то утверждал, что Valgrind находит прямо всё? Это очевидно невозможно.

где очень пытались делать вид, что проблемы не существует,

Это безосновательные спекуляции.