valgrind-based tests

[AvrahamTsaban]

built using standard instructions on recent opensuse tumbleweed. I am using beta rustup (rustc 1.83.0-beta.5 ).

The following tests FAILED:
2 - libclamav_valgrind (Failed)
7 - clamd_valgrind (Failed)
9 - freshclam_valgrind (Failed)
11 - sigtool_valgrind (Failed)

adding ¨lasttest.log¨, should I add any more information?
LastTest.log

[val-ms]

I'm not sure.
It's not a Rust issue, none of the valgrind complaints originate from Rust code.

I investigated the clamd "socket is already closed" issue a little more closely than the others and could not find an actual bug. I tried adding this change to check if a socket is being closed twice, as suggested by the valgrind log, and my tests still passed fine (ubuntu 20.04):

diff --git a/clamd/clamd.c b/clamd/clamd.c
index 191d9a673..15e7dfbd7 100644
--- a/clamd/clamd.c
+++ b/clamd/clamd.c
@@ -859,7 +859,13 @@ int main(int argc, char **argv)
         logg(LOGG_DEBUG, "Closing the main socket%s.\n", (nlsockets > 1) ? "s" : "");

         for (i = 0; i < nlsockets; i++) {
-            closesocket(lsockets[i]);
+            if (lsockets[i] > 0) {
+                closesocket(lsockets[i]);
+                lsockets[i] = -1;
+            } else {
+                printf("Socket %d is already closed\n", i);
+                exit(1);
+            }
         }
 #ifndef _WIN32
         if (nlsockets && localsock) {

The other valgrind complaints also do not make sense to me. Some of them are also for /usr/bin/bash. E.g.:

[INFO]: ==63580== FILE DESCRIPTORS: 14 open (3 std) at exit.
[INFO]: ==63580== Open file descriptor 255: /home/tsaban/Downloads/clamav-1.4.1/unit_tests/input/virusaction-test.sh
[INFO]: ==63580==    at 0x49D740B: dup2 (in /usr/lib64/libc.so.6)
[INFO]: ==63580==    by 0x1A39AA: move_to_high_fd (in /usr/bin/bash)
[INFO]: ==63580==    by 0x12E6C3: main (in /usr/bin/bash)
[INFO]: ==63580== 
[INFO]: {
[INFO]:    <insert_a_suppression_name_here>
[INFO]:    CoreError:FdNotClosed
[INFO]:    fun:dup2
[INFO]:    fun:move_to_high_fd
[INFO]:    fun:main
[INFO]: }

and

[INFO]: ==63740== 624 (32 direct, 592 indirect) bytes in 1 blocks are definitely lost in loss record 337 of 346
[INFO]: ==63740==    at 0x48477C4: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
[INFO]: ==63740==    by 0x17FCCD: xmalloc (in /usr/bin/bash)
[INFO]: ==63740==    by 0x1A2901: make_command (in /usr/bin/bash)
[INFO]: ==63740==    by 0x132810: ??? (in /usr/bin/bash)
[INFO]: ==63740==    by 0x183270: parse_command (in /usr/bin/bash)
[INFO]: ==63740==    by 0x18F42D: read_command (in /usr/bin/bash)
[INFO]: ==63740==    by 0x18F0B8: reader_loop (in /usr/bin/bash)
[INFO]: ==63740==    by 0x12E8CA: main (in /usr/bin/bash)
[INFO]: ==63740== 
[INFO]: {
[INFO]:    <insert_a_suppression_name_here>
[INFO]:    Memcheck:Leak
[INFO]:    match-leak-kinds: definite
[INFO]:    fun:malloc
[INFO]:    fun:xmalloc
[INFO]:    fun:make_command
[INFO]:    obj:/usr/bin/bash
[INFO]:    fun:parse_command
[INFO]:    fun:read_command
[INFO]:    fun:reader_loop
[INFO]:    fun:main
[INFO]: }

Perhaps there may be something wrong with valgrind on your system.

[AvrahamTsaban]

So, should this issue be closed?

[val-ms]

It's not fixed (for you), but I also don't have a solution. Nor do I think it is a real issue. So... I'd love to close it, but I'd understand if you want to keep it open in case someone else runs into the issue and figures out what is going on.