What value does this particular configuration add? Do you know any errors that other configurations don't catch?

Testing a commit that could potentially fail.

Please see https://github.com/async-profiler/async-profiler/actions/runs/17581662920/job/49939353504?pr=1466 for failures about malloc tracer with the gcc version in alpaquita.

All 4 failures are about calloc in nativemem tests.

NativememTests.canAgentTraceMallocCalloc (args: once) (agentArgs: start,nativemem,total,collapsed,file=%f)
NativememTests.canAgentTraceMallocCalloc/VM (args: once) (agentArgs: start,nativemem,total,cstack=vm,collapsed,file=%f)
NativememTests.canAsprofTraceAllNoLeak
NativememTests.canAsprofTraceMallocCalloc

Looks like the same root cause as #1226 (comment), cannot sample calloc.

Note that the calloc_hook_dummy workaround not applicable in this case.

@krk I've checked the issue here & the root cause for the failures is that on Alpaquita musl calloc doesn't call malloc internally

        if (OS::isMusl()) {
            // On musl, calloc() calls malloc() internally, and posix_memalign() calls aligned_alloc().
            // Use dummy hooks to prevent double-accounting. Dummy frames from AP are introduced
            // to preserve the frame link to the original caller (see #1226).
            cc->patchImport(im_calloc, (void*)calloc_hook_dummy);
            cc->patchImport(im_posix_memalign, (void*)posix_memalign_hook_dummy);
        } else {
            cc->patchImport(im_calloc, (void*)calloc_hook);
            cc->patchImport(im_posix_memalign, (void*)posix_memalign_hook);
        }

We assume that if MUSL that calloc would always call malloc internally which seems to be incorrect in this case

Just change the cc->patchImport(im_calloc, (void*)calloc_hook_dummy); to cc->patchImport(im_calloc, (void*)calloc_hook); & it should work (Not a proper fix, but you can try it)

It turns out that in this Alpaquita docker image musl is statically linked with mimalloc (!) which behaves differently from musl's built-in malloc implementation. So, it's not enough to check if the current process runs with glibc or musl, because libc itself can be built with an alternative implementation :-/

Force-pushed to resolve the conflict.