- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am using valgrind for dynamic analysis and have detected a leak. Please confirm.
version: 2024.10 (latest)
Environment: Ubuntu 22.04
sample:
https://github.com/openvinotoolkit/openvino/tree/master/samples/c/hello_Environment:
log:
```
```
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Lazy_bear,
Thanks for reaching out to us.
For your information, I've run Hello Classification C++ Sample with classification.xml file using OpenVINO™ 2024 on Ubuntu 22.04. I also found memory leaks when checking with Valgrind as shown in the attachment below:
G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind -v --tool=memcheck --leak-check=full --num-callers=40 --log-file=valgrind.log ./hello_classification ~/waifook/classification.xml dog.bmp CPU
Let me check with relevant team and I'll update you as soon as possible.
Regards,
Wan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for reply.
I have a question. Is it kind of problem?.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Lazy_bear,
Thanks for your patience.
We've received feedback from the relevant team. Most of the still reachable were caused by extra third parties for operating with images such as OpenCV etc. If remove it, are the results:
==1935021== LEAK SUMMARY:
==1935021== definitely lost: 0 bytes in 0 blocks
==1935021== indirectly lost: 0 bytes in 0 blocks
==1935021== possibly lost: 2,240 bytes in 7 blocks
==1935021== still reachable: 4,756 bytes in 8 blocks
==1935021== of which reachable via heuristic:
==1935021== newarray : 3,096 bytes in 3 blocks
==1935021== suppressed: 0 bytes in 0 blocks
The possibly lost and still reachable are related to TBB, you may refer to valgrind.log for more information. Some of them were caused by dlopen, and Valgrind isn't good when tracking such cases.
For comparison, sanitizers do not show any issues. Memory behavior on example main.cpp with the model from description (classification.xml) is presented in the following attachment:
Because memory values are not continuously increasing, sanitizer doesn't report issues, Valgrind doesn't report guaranteed leaks, and most of the possible leaks are related to TBB (third-party), we suppose there are no real leaks (for the provided use case) in OpenVINO™ toolkit which may be fixed.
Regards,
Wan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for investigation.
I also tried to use sanitizer. But It detected the other error.
What should I do.
~/Release$ ./hello_classification_c ../classification/classification.xml ../car.bmp CPU
---- OpenVINO INFO----
Description : OpenVINO Runtime
Build number: 2024.1.0-14661-2007b7b1b0b
[INFO] Loading model files: ../classification/classification.xml
[INFO] model name: v3-small_224_1.0_float
Top 10 results:
Image ../car.bmp
classid probability
------- -----------
657 0.304511
576 0.141337
469 0.116919
671 0.038865
582 0.031952
818 0.030533
622 0.028456
705 0.022668
655 0.021290
883 0.018246
=================================================================
==79280==ERROR: AddressSanitizer: alloc-dealloc-mismatch (malloc vs operator delete) on 0x7f8fd13c9800
#0 0x7f8fd668ed07 in operator delete(void*) ../../../../src/libsanitizer/asan/asan_new_delete.cpp:160
#1 0x561243ca6eb4 (/home/test/Release/hello_classification_c+0x7eb4)
#2 0x561243ca50ee (/home/test/Release/hello_classification_c+0x60ee)
#3 0x7f8fd6057d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#4 0x7f8fd6057e3f in __libc_start_main_impl ../csu/libc-start.c:392
#5 0x561243ca6734 (/home/test/Release/hello_classification_c+0x7734)
0x7f8fd13c9800 is located 0 bytes inside of 1431339-byte region [0x7f8fd13c9800,0x7f8fd1526f2b)
allocated by thread T0 here:
#0 0x7f8fd668c887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x561243ca703c (/home/test/Release/hello_classification_c+0x803c)
SUMMARY: AddressSanitizer: alloc-dealloc-mismatch ../../../../src/libsanitizer/asan/asan_new_delete.cpp:160 in operator delete(void*)
==79280==HINT: if you don't care about these errors you may set ASAN_OPTIONS=alloc_dealloc_mismatch=0
==79280==ABORTING
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Wan_Intel wrote:
The possibly lost and still reachable are related to TBB, you may refer to valgrind.log for more information. Some of them were caused by dlopen, and Valgrind isn't good when tracking such cases.
Really?
On what authority do you make the claim that Valgrind isn't good at tracking such cases?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Lazy_bear,
Thanks for your information.
Memory behavior on example main.cpp with the model from description (classification.xml) is presented in the following attachment:
You may replace the original main.cpp file with the attached main.cpp file to generate the result.
Regards,
Wan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm checking with hello_classification_c.
Is this C code, isn't it?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Lazy_bear,
Thanks for your patience. The explanation below can applied to hello_classification_c.
Our OpenVINO™ developers informed most of the still reachable were caused by extra third parties used for operating with images such as OpenCV etc.
==1935021== LEAK SUMMARY:
==1935021== definitely lost: 0 bytes in 0 blocks
==1935021== indirectly lost: 0 bytes in 0 blocks
==1935021== possibly lost: 2,240 bytes in 7 blocks
==1935021== still reachable: 4,756 bytes in 8 blocks
==1935021== of which reachable via heuristic:
==1935021== newarray: 3,096 bytes in 3 blocks
==1935021== suppressed: 0 bytes in 0 blocks
For your information, all of the possibly lost and still reachable are related to TBB, please refer to the valgrind.log for more information. Some of them were caused by dlopen.(and Valgrind isn't good when tracking such cases)
Valgrind doesn't report "guaranteed" leaks, and most of the possible leaks are related to TBB (third party), our OpenVINO™ developers suppose there were no real leaks (for the provided use case) in OpenVINO™ toolkit which may be fixed.
Hope it helps.
Regards,
Wan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you so much.
I understand.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Lazy_bear,
Thanks for your question.
If you need any additional information from Intel, please submit a new question as this thread will no longer be monitored.
Regards,
Wan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@lazy_bear wrote:I am using valgrind for dynamic analysis and have detected a leak. Please confirm.
==1267366== Memcheck, a memory error detector==1267366== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.==1267366== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info==1267366== Command: ./hello_classification_c ../classification/classification.xml ../car.bmp CPU==1267366== Parent PID: 1222329==1267366====1267366== Mismatched free() / delete / delete []==1267366== at 0x484C41B: operator delete(void*) (vg_replace_malloc.c:1051)==1267366== by 0x10C524: ??? (in /home/test/Release/hello_classification_c)==1267366== by 0x10BD23: ??? (in /home/test/Release/hello_classification_c)==1267366== by 0x4B1DD8F: (below main) (libc_start_call_main.h:58)==1267366== Address 0x6fc96e0 is 0 bytes inside a block of size 1,431,339 alloc'd==1267366== at 0x48487EF: malloc (vg_replace_malloc.c:442)==1267366== by 0x10C6AC: ??? (in /home/test/Release/hello_classification_c)==1267366== by 0x10C4AC: ??? (in /home/test/Release/hello_classification_c)==1267366== by 0x10B9E2: ??? (in /home/test/Release/hello_classification_c)==1267366== by 0x4B1DD8F: (below main) (libc_start_call_main.h:58)
==1267366== HEAP SUMMARY:==1267366== in use at exit: 9,239 bytes in 22 blocks==1267366== total heap usage: 579,986 allocs, 579,964 frees, 198,346,770 bytes allocated==1267366====1267366== 128 bytes in 1 blocks are still reachable in loss record 1 of 9==1267366== at 0x484A703: operator new[](unsigned long) (vg_replace_malloc.c:725)==1267366== by 0x60ADA5B: ??? (in /usr/lib/x86_64-linux-gnu/libtbb.so.12.5)==1267366== by 0x60ADDE8: ??? (in /usr/lib/x86_64-linux-gnu/libtbb.so.12.5)==1267366== by 0x60AE0EA: ??? (in /usr/lib/x86_64-linux-gnu/libtbb.so.12.5)==1267366== by 0x60A9F32: ??? (in /usr/lib/x86_64-linux-gnu/libtbb.so.12.5)==1267366== by 0x60AA194: tbb::detail::r1::initialize(tbb::detail::d1::task_arena_base&) (in /usr/lib/x86_64-linux-gnu/libtbb.so.12.5)==1267366== by 0x55A4280: ??? (in /home/test/Release/libopenvino.so.2024.1.0)==1267366== by 0x55BC032: ??? (in /home/test/Release/libopenvino.so.2024.1.0)==1267366== by 0x55A743C: ??? (in /home/test/Release/libopenvino.so.2024.1.0)==1267366== by 0x49A4252: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30)==1267366== by 0x4B88AC2: start_thread (pthread_create.c:442)==1267366== by 0x4C19BF3: clone (clone.S:100)
==1267366====1267366== 160 bytes in 1 blocks are still reachable in loss record 2 of 9==1267366== at 0x48487EF: malloc (vg_replace_malloc.c:442)==1267366== by 0x400E146: malloc (rtld-malloc.h:56)==1267366== by 0x400E146: add_to_global_resize (dl-open.c:152)==1267366== by 0x400EFF7: dl_open_worker_begin (dl-open.c:716)==1267366== by 0x4C68C87: _dl_catch_exception (dl-error-skeleton.c:208)==1267366== by 0x400DF99: dl_open_worker (dl-open.c:782)==1267366== by 0x4C68C87: _dl_catch_exception (dl-error-skeleton.c:208)==1267366== by 0x400E34D: _dl_open (dl-open.c:883)==1267366== by 0x4B8463B: dlopen_doit (dlopen.c:56)==1267366== by 0x4C68C87: _dl_catch_exception (dl-error-skeleton.c:208)==1267366== by 0x4C68D52: _dl_catch_error (dl-error-skeleton.c:227)==1267366== by 0x4B8412D: _dlerror_run (dlerror.c:138)==1267366== by 0x4B846C7: dlopen_implementation (dlopen.c:71)==1267366== by 0x4B846C7: dlopen@@GLIBC_2.34 (dlopen.c:81)A leak from dlopen. Are you calling dlclose? Is your exe exiting cleanly?
==1267366== 472 bytes in 1 blocks are still reachable in loss record 6 of 9==1267366== at 0x48487EF: malloc (vg_replace_malloc.c:442)==1267366== by 0x4B7364D: __fopen_internal (iofopen.c:65)==1267366== by 0x4B7364D: fopen@@GLIBC_2.2.5 (iofopen.c:86)==1267366== by 0x10C5A0: ??? (in /home/test/Release/hello_classification_c)==1267366== by 0x10C4AC: ??? (in /home/test/Release/hello_classification_c)==1267366== by 0x10B9E2: ??? (in /home/test/Release/hello_classification_c)==1267366== by 0x4B1DD8F: (below main) (libc_start_call_main.h:58)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page