https://bugs.kde.org/show_bug.cgi?id=426751
Bug ID: 426751
Summary: Valgrind reports «still reachable» memory using musl
(alpine running inside docker)
Product: valgrind
Version: 3.15 SVN
Platform: unspecified
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: memcheck
Assignee: jsew...@acm.org
Reporter: mvano...@dc.uba.ar
Target Milestone: ---
Valgrind fails to detect musl allocations using Alpine under Docker.
A simple hello world program reports 468 bytes as still reachable.
STEPS TO REPRODUCE
1. Download an install docker, and docker-compose.
2. Create a folder with a file named Dockerfile and one named
docker-compose.yml
Dockerfile contents:
```
FROM alpine
RUN apk update && \
apk add vim bash nasm gcc clang gdb valgrind make mandoc man-pages less
libc-dev && \
rm -rf /var/cache/apk/*
RUN mkdir /code
WORKDIR /code
CMD ["/bin/bash"]
```
docker-compose.yml contens:
```
version: '3'
services:
test-musl:
build: .
volumes:
- ./:/code
```
3. Inside the newly created folder, run:
docker-compose build test-musl
docker-compose run test-musl bash
4. Inside docker, create a file named main.c
main.c contents:
```c
#include <stdio.h>
int main(void) {
printf("Hello, World\n");
return 0;
}
```
5. make main
6. valgrind --leak-check=full --show-leak-kinds=all ./main
OBSERVED RESULT
```
bash-5.0# valgrind --leak-check=full --show-leak-kinds=all ./main
==19== Memcheck, a memory error detector
==19== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==19== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==19== Command: ./main
==19==
Hola, Mundo!
==19==
==19== HEAP SUMMARY:
==19== in use at exit: 468 bytes in 4 blocks
==19== total heap usage: 5 allocs, 1 frees, 508 bytes allocated
==19==
==19== 16 bytes in 2 blocks are still reachable in loss record 1 of 3
==19== at 0x48A16F2: calloc (vg_replace_malloc.c:762)
==19== by 0x40590F4: ??? (in /lib/ld-musl-x86_64.so.1)
==19==
==19== 32 bytes in 1 blocks are still reachable in loss record 2 of 3
==19== at 0x48A16F2: calloc (vg_replace_malloc.c:762)
==19== by 0x40590F4: ??? (in /lib/ld-musl-x86_64.so.1)
==19== by 0x57ACD5F4220F7227: ???
==19== by 0x2D616C6F682F2ED2: ???
==19== by 0x3878006F646E756C: ???
==19==
==19== 420 bytes in 1 blocks are still reachable in loss record 3 of 3
==19== at 0x48A16F2: calloc (vg_replace_malloc.c:762)
==19== by 0x4058EBC: ??? (in /lib/ld-musl-x86_64.so.1)
==19== by 0x4059B14: __dls3 (in /lib/ld-musl-x86_64.so.1)
==19== by 0x57ACD5F4220F7227: ???
==19== by 0x2D616C6F682F2ED2: ???
==19== by 0x3878006F646E756C: ???
==19==
==19== LEAK SUMMARY:
==19== definitely lost: 0 bytes in 0 blocks
==19== indirectly lost: 0 bytes in 0 blocks
==19== possibly lost: 0 bytes in 0 blocks
==19== still reachable: 468 bytes in 4 blocks
==19== suppressed: 0 bytes in 0 blocks
==19==
==19== For lists of detected and suppressed errors, rerun with: -s
==19== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
```
EXPECTED RESULT
Nothing showing up in the "still reachable" part.
SOFTWARE/OS VERSIONS
Linux: Ubuntu 20.04 LTS
ADDITIONAL INFORMATION
This bug seems similar to this other one:
https://bugs.kde.org/show_bug.cgi?id=408663
Except that the suppression file posted there doesn't quite work for this use
case.
Generated the suppressions file:
```
{
"Sup 3 test"
Memcheck:Leak
match-leak-kinds: reachable
fun:calloc
obj:/lib/ld-musl-x86_64.so.1
fun:__dls3
obj:*
obj:*
obj:*
}
{
"Sup 2 test"
Memcheck:Leak
match-leak-kinds: reachable
fun:calloc
obj:/lib/ld-musl-x86_64.so.1
obj:*
obj:*
obj:*
}
{
"Sup 1 test"
Memcheck:Leak
match-leak-kinds: reachable
fun:calloc
obj:/lib/ld-musl-x86_64.so.1
}
```
A similar bug reported in stackoverflow:
https://stackoverflow.com/questions/61774643/valgrind-on-alpine-linux
--
You are receiving this mail because:
You are watching all bug changes.
