Musl 1.2.2 is bugged when using valgrind about repo HOT 7 CLOSED

Yeah, so @dilyn-corner apparently this is a valgrind bug. I found some more information on the topic. I guess the fix would have to be made in valgrind.

https://bugs.kde.org/show_bug.cgi?id=435441

I'll poke around at it a bit more. But as of in the state it is now, the allocation tracking feature in valgrind is unusable on musl 1.2.2 .

from repo.

I'm not a master programmer but I know that I can't test this because I can't compile your simple test program.

valgrind can certainly be added to community once you feel comfortable submitting it :)

from repo.

By the way, @dilyn-corner what do you think about adding distcc?
https://github.com/distcc/distcc

I haven't tried this project yet but it looks really cool on paper to compile stuff with.
In May I am waiting for 3 more Ryzen 9 5900x cpu's to deliver, so by then I will definitely
try to experiment with it and build a compiling workstation, that has 36 cores 72 threads total
to compile with. Strange that nobody packaged it, unless it's difficult to set it up, not sure.

from repo.

distcc used to be in community! Was dropped here kiss-community/community@19321f9 when Cem left.
I assume it is not more complicated to setup on KISS than it is anywhere else, but I've never tried it myself. My (one, sad) 3900x might make me want to try it though...

from repo.

@dilyn-corner It happens to be a lot more difficult to fix this in valgrind... For now I have made a tiny workaround patch for musl 1.2 that fixes the malloc problem. Here it is:

diff --git a/../../../1075/build/musl/src/malloc/lite_malloc.c b/./src/malloc/lite_malloc.c
index 43a988f..5e7c69b 100644
--- a/../../../1075/build/musl/src/malloc/lite_malloc.c
+++ b/./src/malloc/lite_malloc.c
@@ -110,9 +110,7 @@ void *__libc_malloc(size_t n)
        return __libc_malloc_impl(n);
 }

-static void *default_malloc(size_t n)
+void *malloc(size_t n)
 {
        return __libc_malloc_impl(n);
 }
-
-weak_alias(default_malloc, malloc);

Works well enough, all it does is change the malloc symbol from weak back to global as it used to be. The musl devs probably decided to make it weak symbol so that there are no linker conflicts if user makes his own malloc it can be overridden, but if that's the case then it is unclear why free() has not been changed as well. The intentions remain unclear to me.

from repo.

The rational behind this particular bit of code is explained here; reading it makes me think either they or we have missed something.

from repo.

Here is a better* explanation. This is the patch that actually went in. Looking at the reasoning I can say that this something so delicate that won't affect me at all, so I can keep using my patch until I or someone else fixes valgrind. Also interposing public malloc is a pretty dumb idea, idk what programmers actually do that and for what gains, but that could be a rant on it's own that I could go on.

from repo.