c programming - difference between compiling in Ubuntu and compiling in Alpine - gcc - valgrind

user_8981014 0
Viewed 283

I'm trying to understand some differences I've noticed when compiling a simple C program with gcc on Ubuntu (canonical ubuntu) and on Alpine (a docker container).

The program is the following:

int main(void)
{
  printf("test\n");
  return 0;
}

The command used to compile is the same for each terminal (Ubuntu and Alpine).

Valgrind detects no error on Ubuntu and 1 error on Alpine:

==311== Invalid free() / delete / delete[] / realloc()
==311==    at 0x4C939EA: free (vg_replace_malloc.c:530)
==311==    by 0x4057B69: ??? (in /lib/ld-musl-x86_64.so.1)
==311==  Address 0x4e9b180 is in a rw- mapped file 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so segment
==311==
test
==311==
==311== HEAP SUMMARY:
==311==     in use at exit: 404 bytes in 1 blocks
==311==   total heap usage: 1 allocs, 1 frees, 404 bytes allocated
==311==
==311== LEAK SUMMARY:
==311==    definitely lost: 0 bytes in 0 blocks
==311==    indirectly lost: 0 bytes in 0 blocks
==311==      possibly lost: 0 bytes in 0 blocks
==311==    still reachable: 404 bytes in 1 blocks
==311==         suppressed: 0 bytes in 0 blocks
==311== Rerun with --leak-check=full to see details of leaked memory
==311==
==311== For counts of detected and suppressed errors, rerun with: -v
==311== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

What is the explanation for that?

alpine-linux ubuntu gcc valgrind c
1 Answers

Valgrind calls special glibc functions to deallocate memory on process exit (while normally, glibc just lets the kernel do that). Musl likely doesn't have that because it is poor bloat.

Valgrind also has suppression files to deal with false positives or useless reports from system libraries. Some porting work is required to create them, and it looks like Alpine hasn't done that yet, or the files have become obsolete due to further musl development.

Sometimes, suppression files require debuginfo symbols, and valgrind couldn't find them in the run you quoted, so this is another thing to try.

user_83163150
Related