cv::resize function producing memory leak
Problem: memory leak detected by valgrind when using resize func.
OpenCV version: 3.3.0 OS: Ubuntu 16.04 Valgrind version: 3.11.0
int main() {
VideoCapture vcap("video.mp4");
Mat frame;
VideoWriter video("live.mp4", CV_FOURCC('X','2','6','4') , vcap.get( CAP_PROP_FPS ), frame.size(), true);
for (;;) {
vcap >> frame;
cv::resize(frame, frame, Size(640, 480));
video.write(frame);
char c = (char)waitKey(1);
if (c == 27 || i==100) {
video.release();
break;
}
}
vcap.release();
return 0;
}
Here is the log summary:
HEAP SUMMARY:
==20157== in use at exit: 216,660 bytes in 936 blocks
==20157== total heap usage: 20,658 allocs, 19,722 frees, 2,199,353,656 bytes allocated
==20157==
==20157== Searching for pointers to 936 not-freed blocks
==20157== Checked 20,692,904 bytes
==20157==
==20157== 4 bytes in 1 blocks are still reachable in loss record 1 of 275
==20157== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==20157== by 0xDF37132: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.2)
==20157== by 0xDF37674: g_private_get (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.2)
==20157== by 0xDF0F8FC: g_slice_alloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.2)
==20157== by 0xDEE174D: g_hash_table_new_full (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.2)
==20157== by 0xDF028AA: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.2)
==20157== by 0x40106B9: call_init.part.0 (dl-init.c:72)
==20157== by 0x40107CA: call_init (dl-init.c:30)
==20157== by 0x40107CA: _dl_init (dl-init.c:120)
==20157== by 0x4000C69: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==20157==
==20157== 8 bytes in 1 blocks are still reachable in loss record 2 of 275
==20157== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==20157== by 0x214EC778: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==20157== by 0x214F5647: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==20157== by 0x214EADE1: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==20157== by 0x40106B9: call_init.part.0 (dl-init.c:72)
==20157== by 0x40107CA: call_init (dl-init.c:30)
==20157== by 0x40107CA: _dl_init (dl-init.c:120)
==20157== by 0x4000C69: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==20157==
==20157== 8 bytes in 1 blocks are still reachable in loss record 3 of 275
==20157== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==20157== by 0x4C2FDEF: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==20157== by 0xDEF87D7: g_realloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.2)
==20157== by 0xDC829D8: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2)
==20157== by 0xDC882CC: g_type_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2)
==20157== by 0xDC8CE31: g_type_plugin_get_type (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2)
==20157== by 0xDC61165: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2)
==20157== by 0x40106B9: call_init.part.0 (dl-init.c:72)
==20157== by 0x40107CA: call_init (dl-init.c:30)
==20157== by 0x40107CA: _dl_init (dl-init.c:120)
==20157== by 0x4000C69: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==20157==
==20157== 8 bytes in 1 blocks are still reachable in loss record 4 of 275
==20157== at 0x4C2DB8F: malloc (in /usr/lib ...
Probably they are false positives.
See:
Thank you for your prompt reply.