Memory leaks reported using musl libc

[nsudsgaard]

Describe the bug

I am working on updating the package for Void Linux and when testing ClamAV 1.2.1 the following tests fail. This only happens when using musl libc.

• clamscan_valgrind
• clamd_valgrind
• freshclam_valgrind

My dumb guess from looking at the logs would be that these are false-positives.

How to reproduce the problem

As far as I know, building and testing using musl libc.

No special configuration was done. While probably not necessary the build script can be found here.

Attachments

clamav-1.2.1-musl-valgrind-logs.zip I hope I provided the correct log files.

[micahsnyder]

The logs you shared report these leaks:

These are:

• the clamscan --version test
• the clamd --version test
• two of the clamdscan tests for the ExcludePath feature.
• the freshclam --version test

I think it's very weird that the --version tests would report leaks. They don't really do much. Note there are also no leaks found for the tests that scan a bunch of stuff.

Unfortunately, this was a Release-mode build so there no debug symbols and the valgrind output is otherwise useless. All I can see is:

[INFO]: ==3778== 
[INFO]: ==3778== 640 bytes in 1 blocks are definitely lost in loss record 2 of 4
[INFO]: ==3778==    at 0x48C580F: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
[INFO]: ==3778==    by 0x4077609: __dls3 (dynlink.c:1894)
[INFO]: ==3778==    by 0x4076F0D: __dls2 (dynlink.c:1650)
[INFO]: ==3778==    by 0x4079C09: ??? (in /usr/lib/libc.so)
[INFO]: ==3778==    by 0x6: ???
[INFO]: ==3778==    by 0x1FFEFFF5AE: ???
[INFO]: ==3778==    by 0x1FFEFFF5DF: ???
[INFO]: ==3778==    by 0x1FFEFFF5E6: ???
[INFO]: ==3778==    by 0x1FFEFFF5E8: ???
[INFO]: ==3778==    by 0x1FFEFFF5EF: ???
[INFO]: ==3778==    by 0x1FFEFFF623: ???
[INFO]: ==3778==    by 0x1FFEFFF626: ???
[INFO]: ==3778== 
[INFO]: {
[INFO]:    <insert_a_suppression_name_here>
[INFO]:    Memcheck:Leak
[INFO]:    match-leak-kinds: definite
[INFO]:    fun:calloc
[INFO]:    fun:__dls3
[INFO]:    fun:__dls2
[INFO]:    obj:/usr/lib/libc.so
[INFO]:    obj:*
[INFO]:    obj:*
[INFO]:    obj:*
[INFO]:    obj:*
[INFO]:    obj:*
[INFO]:    obj:*
[INFO]:    obj:*
[INFO]:    obj:*
[INFO]: }
[INFO]: ==3778== LEAK SUMMARY:
[INFO]: ==3778==    definitely lost: 640 bytes in 1 blocks
[INFO]: ==3778==    indirectly lost: 0 bytes in 0 blocks
[INFO]: ==3778==      possibly lost: 0 bytes in 0 blocks
[INFO]: ==3778==    still reachable: 8,593 bytes in 22 blocks
[INFO]: ==3778==         suppressed: 1,136 bytes in 26 blocks
[INFO]: ==3778== Reachable blocks (those to which a pointer was found) are not shown.
[INFO]: ==3778== To see them, rerun with: --leak-check=full --show-leak-kinds=all
[INFO]: ==3778== 

(those ??? and `obj:*`` should be function names with line numbers that tell me where the leak is)

If you can do a build in Debug mode and provide the logs from those, that will help. Otherwise there is nothing I can do further.

[nsudsgaard]

That's odd since it was built in debug mode (i.e. CMAKE_BUILD_TYPE=Debug).

Looking at the valgrind logs above it seems like the "leaks" are occurring in places such as __dls3 which, as far as I know, are code in libc used when linking shared libraries.

I checked the shared libraries that clamscan is linked against and one of them was libclamav so I compiled the following code with -lclamav and it reports memory leaks.

int main()
{
        return 0;
}

==19938== Memcheck, a memory error detector
==19938== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==19938== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==19938== Command: ./main
==19938== 
==19938== 
==19938== HEAP SUMMARY:
==19938==     in use at exit: 6,053 bytes in 29 blocks
==19938==   total heap usage: 31 allocs, 2 frees, 78,893 bytes allocated
==19938== 
==19938== 560 bytes in 1 blocks are definitely lost in loss record 3 of 4
==19938==    at 0x48C580F: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==19938==    by 0x4077609: __dls3 (dynlink.c:1894)
==19938==    by 0x4076F0D: __dls2 (dynlink.c:1650)
==19938==    by 0x4079C09: ??? (in /usr/lib/libc.so)
==19938== 
==19938== LEAK SUMMARY:
==19938==    definitely lost: 560 bytes in 1 blocks
==19938==    indirectly lost: 0 bytes in 0 blocks
==19938==      possibly lost: 0 bytes in 0 blocks
==19938==    still reachable: 4,717 bytes in 12 blocks
==19938==         suppressed: 776 bytes in 16 blocks
==19938== Reachable blocks (those to which a pointer was found) are not shown.
==19938== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==19938== 
==19938== For lists of detected and suppressed errors, rerun with: -s
==19938== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

My best guess so far would be this being an issue with valgrind, as musl and valgrind has always had a bit of a "eeh" relationship.

[nsudsgaard]

I was hoping valgrind suppressions would be added. But I'm going to assume you decided that this is out of scope for ClamAV. Therefore, I will be closing this issue. Thanks for your time though.