Valgrind memory leak

lazy_bear · ‎03-07-2024

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:

https://storage.openvinotoolkit.org/repositories/openvino_notebooks/models/002-example-models/classification.xml

log:

```

==1267366== Memcheck, a memory error detector

==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==

==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)

==1267366==

==1267366== 213 bytes in 4 blocks are still reachable in loss record 3 of 9

==1267366== at 0x48487EF: malloc (vg_replace_malloc.c:442)

==1267366== by 0x40271DF: malloc (rtld-malloc.h:56)

==1267366== by 0x40271DF: strdup (strdup.c:42)

==1267366== by 0x400A588: _dl_map_object (dl-load.c:2259)

==1267366== by 0x400E9A8: dl_open_worker_begin (dl-open.c:534)

==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==

==1267366== 213 bytes in 4 blocks are still reachable in loss record 4 of 9

==1267366== at 0x48487EF: malloc (vg_replace_malloc.c:442)

==1267366== by 0x400DD20: malloc (rtld-malloc.h:56)

==1267366== by 0x400DD20: _dl_new_object (dl-object.c:199)

==1267366== by 0x4008C82: _dl_map_object_from_fd (dl-load.c:1063)

==1267366== by 0x400A600: _dl_map_object (dl-load.c:2327)

==1267366== by 0x400E9A8: dl_open_worker_begin (dl-open.c:534)

==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==

==1267366== 320 bytes in 1 blocks are possibly lost in loss record 5 of 9

==1267366== at 0x484FF50: calloc (vg_replace_malloc.c:1595)

==1267366== by 0x40147D9: calloc (rtld-malloc.h:44)

==1267366== by 0x40147D9: allocate_dtv (dl-tls.c:375)

==1267366== by 0x40147D9: _dl_allocate_tls (dl-tls.c:634)

==1267366== by 0x4B897B4: allocate_stack (allocatestack.c:430)

==1267366== by 0x4B897B4: pthread_create@@GLIBC_2.34 (pthread_create.c:647)

==1267366== by 0x49A4328: std::thread::_M_start_thread(std::unique_ptr<std::thread::_State, std::default_delete<std::thread::_State> >, void (*)()) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30)

==1267366== by 0x55A4951: void std::vector<std::thread, std::allocator<std::thread> >::_M_realloc_insert<ov::threading::CPUStreamsExecutor::Impl::Impl(ov::threading::IStreamsExecutor::Config const&)::{lambda()#2}>(__gnu_cxx::__normal_iterator<std::thread*, std::vector<std::thread, std::allocator<std::thread> > >, ov::threading::CPUStreamsExecutor::Impl::Impl(ov::threading::IStreamsExecutor::Config const&)::{lambda()#2}&&) (in /home/test/Release/libopenvino.so.2024.1.0)

==1267366== by 0x55A91D8: ??? (in /home/test/Release/libopenvino.so.2024.1.0)

==1267366== by 0x55A9724: ov::threading::CPUStreamsExecutor::CPUStreamsExecutor(ov::threading::IStreamsExecutor::Config const&) (in /home/test/Release/libopenvino.so.2024.1.0)

==1267366== by 0x7582B38: ??? (in /home/test/Release/libopenvino_intel_cpu_plugin.so)

==1267366== by 0x81D60DB: ??? (in /home/test/Release/libopenvino_intel_cpu_plugin.so)

==1267366== by 0x559E03D: ??? (in /home/test/Release/libopenvino.so.2024.1.0)

==1267366== by 0x557690C: ??? (in /home/test/Release/libopenvino.so.2024.1.0)

==1267366== by 0x554E51D: ov::Core::compile_model(std::shared_ptr<ov::Model const> const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, ov::Any, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, ov::Any> > > const&) (in /home/test/Release/libopenvino.so.2024.1.0)

==1267366==

==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)

==1267366==

==1267366== 640 bytes in 2 blocks are possibly lost in loss record 7 of 9

==1267366== at 0x484FF50: calloc (vg_replace_malloc.c:1595)

==1267366== by 0x40147D9: calloc (rtld-malloc.h:44)

==1267366== by 0x40147D9: allocate_dtv (dl-tls.c:375)

==1267366== by 0x40147D9: _dl_allocate_tls (dl-tls.c:634)

==1267366== by 0x4B897B4: allocate_stack (allocatestack.c:430)

==1267366== by 0x4B897B4: pthread_create@@GLIBC_2.34 (pthread_create.c:647)

==1267366== by 0x60B743B: ??? (in /usr/lib/x86_64-linux-gnu/libtbb.so.12.5)

==1267366== by 0x60B8026: ??? (in /usr/lib/x86_64-linux-gnu/libtbb.so.12.5)

==1267366== by 0x4B88AC2: start_thread (pthread_create.c:442)

==1267366== by 0x4C19BF3: clone (clone.S:100)

==1267366==

==1267366== 2,112 bytes in 4 blocks are still reachable in loss record 8 of 9

==1267366== at 0x484FF50: calloc (vg_replace_malloc.c:1595)

==1267366== by 0x40162DC: calloc (rtld-malloc.h:44)

==1267366== by 0x40162DC: _dl_check_map_versions (dl-version.c:273)

==1267366== by 0x400ED13: dl_open_worker_begin (dl-open.c:600)

==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)

==1267366==

==1267366== 4,981 bytes in 4 blocks are still reachable in loss record 9 of 9

==1267366== at 0x484FF50: calloc (vg_replace_malloc.c:1595)

==1267366== by 0x400DA02: calloc (rtld-malloc.h:44)

==1267366== by 0x400DA02: _dl_new_object (dl-object.c:92)

==1267366== by 0x4008C82: _dl_map_object_from_fd (dl-load.c:1063)

==1267366== by 0x400A600: _dl_map_object (dl-load.c:2327)

==1267366== by 0x400E9A8: dl_open_worker_begin (dl-open.c:534)

==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==

==1267366== LEAK SUMMARY:

==1267366== definitely lost: 0 bytes in 0 blocks

==1267366== indirectly lost: 0 bytes in 0 blocks

==1267366== possibly lost: 960 bytes in 3 blocks

==1267366== still reachable: 8,279 bytes in 19 blocks

==1267366== suppressed: 0 bytes in 0 blocks

==1267366==

==1267366== For lists of detected and suppressed errors, rerun with: -s

==1267366== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)

```

Wan_Intel · ‎03-08-2024

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

memory leak.jpg

Let me check with relevant team and I'll update you as soon as possible.

Regards,

Wan

lazy_bear · ‎03-14-2024

Thank you for reply.

I have a question. Is it kind of problem?.

Wan_Intel · ‎03-16-2024

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

lazy_bear · ‎03-17-2024

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

paul_f · ‎07-01-2024

@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?

Wan_Intel · ‎03-18-2024

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

lazy_bear · ‎03-21-2024

I'm checking with hello_classification_c.

Is this C code, isn't it?

Wan_Intel · ‎03-24-2024

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

lazy_bear · ‎03-26-2024

Thank you so much.

I understand.

Wan_Intel · ‎04-04-2024

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

paul_f · ‎07-01-2024

@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)

Valgrind sees that you are allocating with malloc and deallocating with delete. Either this is a genuine error in your code or else your optimized build is doing something like inlining that hides a call to operator new.

==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)

This looks like a thread that is not bing joined.

==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?

2 more dlopen leaks elided.

1 pthread_create elided.

==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)

Are you calling fclose?

3 more delpen/pthread creates.

The real question is whether you can call pthread_join/fclose/dlclose or not. They mayb be called from libraries that are leaking.