Будут ли «все еще достижимые» утечки памяти VALGRIND (Linux) связаны с ростом памяти PRSTAT на SOLARIS?

Question

Я использую Valgrind для проверки утечек в написанном мною приложении C.

Я использую сторонние библиотеки ... но не уверен на 100%, действительно ли проблема заключается только в них.Если я запускаю 10 сообщений через мой код, я получаю следующее в Linux:

==12460== LEAK SUMMARY:
==12460==    definitely lost: 70,794 bytes in 11 blocks
==12460==    indirectly lost: 0 bytes in 0 blocks
==12460==      possibly lost: 69,960 bytes in 19 blocks
==12460==    still reachable: 52,095 bytes in 33 blocks
==12460==         suppressed: 0 bytes in 0 blocks

Если я запускаю 100 сообщений через мой код, я получаю:

==12811== LEAK SUMMARY:
==12811==    definitely lost: 70,794 bytes in 11 blocks
==12811==    indirectly lost: 0 bytes in 0 blocks
==12811==      possibly lost: 69,960 bytes in 19 blocks
==12811==    still reachable: 61,795 bytes in 133 blocks
==12811==         suppressed: 0 bytes in 0 blocks

Таким образом, вы можетеПонимаете, "все еще достижимо" - это единственное, что действительно растет здесь ... будет ли это связано с тем фактом, что когда я передаю этот код в Solaris, я вижу, что поле SIZE в PRSTAT через некоторое время увеличивается?Я бы предположил, что «все еще достижимо» - все еще «утечка памяти»?

Примером «все еще достижимости» в моем журнале Valgrind будет что-то вроде:

==12811== 848 bytes in 1 blocks are still reachable in loss record 34 of 48
==12811==    at 0x4A067BA: malloc (vg_replace_malloc.c:263)
==12811==    by 0x656F1A7: xppInitialize (in /opt/mqm/lib64/libmqmcs.so)
==12811==    by 0x6538802: InitProcessInitialisation (in /opt/mqm/lib64/libmqmcs.so)
==12811==    by 0x653A3D4: xcsInitializeEx (in /opt/mqm/lib64/libmqmcs.so)
==12811==    by 0x653AF94: xcsInitialize (in /opt/mqm/lib64/libmqmcs.so)
==12811==    by 0x6250BAC: zstMQCONNX (in /opt/mqm/lib64/libmqz.so)
==12811==    by 0x60B1605: MQCONNX (in /opt/mqm/lib64/libmqm.so)
==12811==    by 0x585CEBA: wmq_receiver_initialize (wmq_receiver.c:18)
==12811==    by 0x4E10D58: wmq_receiver_proxy_initialize (wmq_receiver_proxy.c:17)
==12811==    by 0x402D02: initialiseWMQReceiverProxy (test_outbound.c:296)
==12811==    by 0x4027E8: outboundThreadMainLoop (test_outbound.c:209)
==12811==    by 0x37EA2077E0: start_thread (in /lib64/libpthread-2.12.so)

Новыше в сторонней библиотеке IBM?Но я не могу поверить, что IBM (для Websphere MQ) будет иметь утечки в своей библиотеке, так как она используется годами и годами ... могу ли я что-то здесь упустить?

Любой способ лучше отследить и исправитьэти "все еще достижимые" утечки?Полагаю, я прав, говоря, что это может быть причиной того, что я вижу постепенный рост памяти в Solaris после портирования приложения ...

Спасибо за помощь; -)

Lynton

Answer 1

«все еще достижимо» обычно означает, что в коде есть некоторая статическая (или локальная для потока) переменная-указатель, которая инициализируется с помощью malloc & Co. То, что эта часть растет в сторонней библиотеке, может указывать на то, что эта библиотека делает время от времени масштабируйте его буферы, чтобы справляться с растущими запросами. Но так как кажется, что нет никаких дополнительных «окончательно потерянных» действий, это, кажется, делает это хорошо, например, используя realloc.

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

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

Answer 2

«все еще достижимо» означает, что существуют допустимые указатели на эти выделенные блоки где-то в коде.Так что это не традиционная утечка - память теоретически все еще может быть освобождена.Вы правы, что это будет учтено в prstat в метрике SIZE.

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