New comment by tornaria on void-packages repository https://github.com/void-linux/void-packages/pull/34030#issuecomment-1001042266 Comment: > You shouldn't even need `musl-dbg`, actually. We don't strip libc. It just needs to be built with debug info. Hmm... I rebuilt musl using `./xbps-src -t -g pkg musl` and then I installed `musl-dbg` on the chroot. Maybe what happened is that I did not reinstall `musl` in the chroot so I'm using the old (built without -g) one. In any case, here's a temporary patch for sagemath that seems to fix the issue (at least `Integer.factorial(27)` works now). I'll submit something more robust (and less overhead since this is *really* an important hotpath for computations: allocation of integers no less) to sage trac, but at least you can try to see if this fixes doctests. ```diff --- a/src/sage/rings/integer.pyx 2021-12-12 07:19:28.000000000 -0300 +++ b/src/sage/rings/integer.pyx 2021-12-25 13:00:21.719904604 -0300 @@ -7345,7 +7349,7 @@ # Applications expecting to be compatible with future releases should use # only the documented interfaces described in previous chapters." new_mpz = ((new).value) - new_mpz._mp_d = check_malloc(GMP_LIMB_BITS >> 3) + new_mpz._mp_d = check_malloc((new_mpz._mp_alloc)*(GMP_LIMB_BITS >> 3)) # This line is only needed if Python is compiled in debugging mode # './configure --with-pydebug' or SAGE_DEBUG=yes. If that is the ``` Oh, yes, yes, they are assuming `_mp_alloc=1` so they only allocate 8 bytes but in fact `_mp_alloc=2` so gmp (rightly) uses 16 bytes! It seems glibc and old musl allocate at least 16 bytes anyway so it hasn't developed into a problem, but new musl allocates exactly 8 bytes and uses the next 8 bytes for some malloc data that later makes realloc to segfault. The fact that `_mp_alloc=2` has nothing to do with musl libc and this bug is present in sage 9.4 without biting AFAIK so it really means typical allocators are very lenient on this. @dkwo can you try again with this patch and see if now doctests pass or is there another issue?