LINUX.ORG.RU

[SOLVED]valgrind: still reachable

 ,


0

1
==1951== Memcheck, a memory error detector
==1951== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1951== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==1951== Command: ./test.out
==1951== 
==1951== 
==1951== HEAP SUMMARY:
==1951==     in use at exit: 472 bytes in 1 blocks
==1951==   total heap usage: 6 allocs, 5 frees, 77,323 bytes allocated
==1951== 
==1951== LEAK SUMMARY:
==1951==    definitely lost: 0 bytes in 0 blocks
==1951==    indirectly lost: 0 bytes in 0 blocks
==1951==      possibly lost: 0 bytes in 0 blocks
==1951==    still reachable: 472 bytes in 1 blocks
==1951==         suppressed: 0 bytes in 0 blocks
==1951== Rerun with --leak-check=full to see details of leaked memory
==1951== 
==1951== For lists of detected and suppressed errors, rerun with: -s
==1951== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Вопрос: это linux «лениво» освобождает память, или программист я чего-то не освободил?

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



Последнее исправление: n0name_anonymous (всего исправлений: 1)

Rerun with --leak-check=full to see details of leaked memory

anonymous
()
Ответ на: комментарий от hobbit

it didn’t free some memory it could have

Программа не освободила память, которую могла иметь? Не понимаю.

Т.е. память была выделена, но не была освобождена? Т.е. проблема в коде, и какая-то память выделяется, но не освобождается?

n0name_anonymous
() автор топика
Ответ на: комментарий от Siborgium

Нет кода – нет ответа.

Сформулирую иначе: возможно ли, что каждая выделенная в куче память освобождается в коде программы, но still reachable не нуль?

n0name_anonymous
() автор топика
Ответ на: комментарий от xaizek

Сформулирую иначе: возможно ли, что каждая выделенная в куче память освобождается в коде программы, но still reachable не нуль?

Если выделение памяти произошло в библиотеке, то возможно.

Ясно. Возможно ли, что какая-то выделенная в коде программы память не освобождается в коде программы, но:

==1951== LEAK SUMMARY:
==1951==    definitely lost: 0 bytes in 0 blocks
==1951==    indirectly lost: 0 bytes in 0 blocks
==1951==      possibly lost: 0 bytes in 0 blocks
==1951==    still reachable: 472 bytes in 1 blocks
==1951==         suppressed: 0 bytes in 0 blocks

n0name_anonymous
() автор топика
Ответ на: комментарий от n0name_anonymous

Тоже может быть. Где-то остаётся указатель достижимый из глобальной памяти или статической переменной. --leak-check=full --show-reachable=yes должно показать, о какой именно памяти идёт речь.

xaizek ★★★★★
()

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

Пример:

#include <stdlib.h>

void* a;

int main()
{
   a = malloc(472);
}
valgrind ./a.out 
==16023== Memcheck, a memory error detector
==16023== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==16023== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==16023== Command: ./a.out
==16023== 
==16023== 
==16023== HEAP SUMMARY:
==16023==     in use at exit: 472 bytes in 1 blocks
==16023==   total heap usage: 1 allocs, 0 frees, 472 bytes allocated
==16023== 
==16023== LEAK SUMMARY:
==16023==    definitely lost: 0 bytes in 0 blocks
==16023==    indirectly lost: 0 bytes in 0 blocks
==16023==      possibly lost: 0 bytes in 0 blocks
==16023==    still reachable: 472 bytes in 1 blocks
==16023==         suppressed: 0 bytes in 0 blocks
==16023== Rerun with --leak-check=full to see details of leaked memory
==16023== 
==16023== For lists of detected and suppressed errors, rerun with: -s
==16023== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

P.S. это «типа норм» считается, например, PVS-Studio говорили что они только выделяют память, а освобождает сама система, после того как программа завершит анализ файла. Ещё Уолтер Брайт говорил, что в его dmd dlang compiler память только выделяется, а освободится системой, и это одна из фич, которая позволяет компилятору D быстрее собирать код, чем другим компиляторам…

fsb4000 ★★★★★
()
Последнее исправление: fsb4000 (всего исправлений: 1)
Ответ на: комментарий от fsb4000

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

Спасибо. Разобрался

n0name_anonymous
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.