2

Trying to setup automatic memory leak tests on gitlab-ci I noticed that Valgrind have some problems with musl libc.

.gitlab-ci.yml:

.alpine_cmake: &alpine_cmake
  image: alpine
  before_script:
    - apk update
    - apk add build-base gcc abuild binutils
    - apk add cmake extra-cmake-modules
    - apk add valgrind

make:
  stage: build
  <<: *alpine_cmake
  script:
    - ./configure
    - cd build
    - make all
  artifacts:
    expose_as: build
    paths: [build]

test_and_memcheck:
  stage: test
  <<: *alpine_cmake
  script:
    - cd build
    - make test_memcheck
    - '[ -s "Testing/Temporary/MemoryChecker.*.log" ]'

CMakeLists.txt:

cmake_minimum_required(VERSION 3.0.0)
project(TEST VERSION 1.0.0 LANGUAGES C)
set(CMAKE_C_STANDARD 99)

# TEST TARGET
include (CTest)
add_executable(test test.c)
add_test(TEST test)
add_custom_target(
  test_memcheck
  COMMAND ${CMAKE_CTEST_COMMAND} --force-new-ctest-process --test-action memcheck
  COMMAND cat "${CMAKE_BINARY_DIR}/Testing/Temporary/MemoryChecker.*.log"
)

Result:

$ make test_memcheck
-- Configuring done
-- Generating done
-- Build files have been written to: /builds/<PATH>/build
Scanning dependencies of target test_memcheck
   Site: runner-ed2dce3a-project-18678923-concurrent-0
   Build name: Linux-cc
Create new tag: 20200513-1037 - Experimental
Memory check project /builds/<PATH>/build
    Start 1: TEST
1/1 MemCheck #1: TEST ...........................   Passed    0.26 sec
100% tests passed, 0 tests failed out of 1
Total Test time (real) =   0.52 sec
-- Processing memory checking output:
1/1 MemCheck: #1: TEST .............................   Defects: 4
MemCheck log files can be found here: ( * corresponds to test number)
/builds/<PATH>/build/Testing/Temporary/MemoryChecker.*.log
Memory checking results:
Potential Memory Leak - 8
==39== 32 bytes in 3 blocks are still reachable in loss record 1 of 4
==39==    at 0x48A16F2: calloc (vg_replace_malloc.c:762)
==39==    by 0x4059049: ??? (in /lib/ld-musl-x86_64.so.1)
==39== 
==39== 40 bytes in 1 blocks are still reachable in loss record 2 of 4
==39==    at 0x48A16F2: calloc (vg_replace_malloc.c:762)
==39==    by 0x4059049: ??? (in /lib/ld-musl-x86_64.so.1)
==39==    by 0x74C8CD95484B3A94: ???
==39==    by 0x73646C6975622F58: ???
==39==    by 0x636E616D4450442E: ???
==39==    by 0x65676F72702F6C74: ???
==39==    by 0x6E6962616C6F7473: ???
==39==    by 0x6975622F666E6966: ???
==39==    by 0x2F747365742F646B: ???
==39==    by 0x745F726F74636575: ???
==39==    by 0x5F36387800747364: ???
==39== 
==39== 420 bytes in 1 blocks are still reachable in loss record 3 of 4
==39==    at 0x48A16F2: calloc (vg_replace_malloc.c:762)
==39==    by 0x4058E11: ??? (in /lib/ld-musl-x86_64.so.1)
==39==    by 0x4059A64: __dls3 (in /lib/ld-musl-x86_64.so.1)
==39==    by 0x74C8CD95484B3A94: ???
==39==    by 0x73646C6975622F58: ???
==39==    by 0x636E616D4450442E: ???
==39==    by 0x65676F72702F6C74: ???
==39==    by 0x6E6962616C6F7473: ???
==39==    by 0x6975622F666E6966: ???
==39==    by 0x2F747365742F646B: ???
==39==    by 0x745F726F74636575: ???
==39==    by 0x5F36387800747364: ???
==39== 
==39== 427 bytes in 1 blocks are still reachable in loss record 4 of 4
==39==    at 0x48A16F2: calloc (vg_replace_malloc.c:762)
==39==    by 0x4058E11: ??? (in /lib/ld-musl-x86_64.so.1)
==39==    by 0x40590D2: ??? (in /lib/ld-musl-x86_64.so.1)
==39== 
Built target test_memcheck
$ [ -s "Testing/Temporary/MemoryChecker.*.log" ]
Running after_script
00:01
Uploading artifacts for failed job
00:02
ERROR: Job failed: exit code 1

On my machine (Manjaro with gcc and glibc) it doesn't flag any memory leak.

I could use Debian instead, but Alpine is very useful because it's fast to load its docker image, so I'm looking if there's a way to use Valgrind on Alpine.

== UPDATE ==
I created a repo with an example: https://gitlab.com/DPDmancul/valgrindtest

DPD-
  • 412
  • 1
  • 5
  • 15
  • Interesting. Could you post `test.c`? – valiano May 17 '20 at 18:38
  • 1
    It's a complex source code (5 libraries, which I omitted above to reduce the output), but briefly the dynamic allocation is used for simple growing vectors. Reading the log it seems the problem is not in the code but in the musl library, more specifically in `vg_replace_malloc.c` which seems to replace malloc calls with calloc ones. – DPD- May 19 '20 at 12:13
  • 1
    @valiano I created a repo with an example (removing from my code all which is not necessary) https://gitlab.com/DPDmancul/valgrindtest – DPD- May 20 '20 at 09:01
  • 1
    I'm seeing a similar issue with valgrind. Reported it [here](https://bugs.kde.org/show_bug.cgi?id=426751) – Marco Sep 19 '20 at 22:47
  • Did you ever find a resolution for this? I'm having this issue with a very barebones codebase that I just started. I think I'll probably just switch the image to something else, but it would be nice to use alpine if I can get it to work. – Kyle Anderson May 16 '21 at 23:37

0 Answers0