mcandre
February 10, 2026, 10:01pm
1
Hi,
My buildx builds recently began emitting:
=> [linux/ppc64le build 5/5] RUN cargo build --release 27.7s
And the builds seem to stall for hours on end. buildx fails to properly detect the qemu errors.
This happens with linux/riscv64, linux/ppc64le, and likely other buildx platforms as well.
Is this problem caused by the Docker buildx subsystem? Perhaps the library/alpine and library/debian base images on Docker Hub?
Tried deleting and recreating the buildx builder, same behavior.
Tried docker system prune -f, same behavior.
Tried rebooting, same behavior.
Latest stable Docker Desktop, macOS Sequoia, Apple Silicon.
rimelek
February 10, 2026, 10:33pm
2
Qemu is an emulator, so it seems like a problem with emulated architecture so it doesn’t look like directly caused by Docker Desktop unless it is a qemu version issue. If I search for the error message, I find other Qemu topis like this
opened 07:36AM - 17 Nov 23 UTC
- Clang version: 16.0.6 (15)
- Linux distribution: Ubuntu 23.10
- Linux kernel… version: `Linux ubuntu 6.5.0-9-generic #9.1-Ubuntu`
- Machine: QEMU version 7.2.6, `qemu-system-riscv64 -machine virt`
---
On any RISC-V 64 Linux systems using SV48 virtual address scheme (for example, with sufficiently recent versions of QEMU and Linux kernel), build and run any C program with ASAN enabled, for example:
```sh
echo 'int main() {}' > test.c
clang -fsanitize=address test.c
./a.out
```
This results in the following error when running `./a.out`:
```
kazurin@ubuntu:~$ ./a.out
AddressSanitizer: CHECK failed: sanitizer_allocator_primary32.h:292 "((res)) < ((kNumPossibleRegions))" (0x7fff842, 0x40000) (tid=1315)
<empty stack>
```
Note that in the error message, the first argument value `0x7fff842` resembles the upper half of a 47-bit virtual memory address in the target program, while the second argument value `0x40000` resembles the upper limit of a 38-bit address space. This clearly indicates lack of support for 48-bit virtual address space (aka. SV48) on RISC-V (i.e. only the plain-old SV39 is supported).
---
As a temporary workaround for this problem, I had to manually disable SV48 support in QEMU by modifying `qemu/target/riscv/csr.c` and recompiling `qemu-system-riscv64`:
```diff
static const char valid_vm_1_10_64[16] = {
[VM_1_10_MBARE] = 1,
[VM_1_10_SV39] = 1,
- [VM_1_10_SV48] = 1,
- [VM_1_10_SV57] = 1
+ [VM_1_10_SV48] = 0,
+ [VM_1_10_SV57] = 0
};
/* Machine Information Registers */
```
This would solve my problem and make programs compiled with ASAN work as expected.
.
mcandre
February 13, 2026, 7:01pm
3
buildx didn’t used to trigger this problem.
Perhaps buildx recently upgraded to a buggy qemu/libvirt version?
rimelek
February 16, 2026, 10:09pm
4
Sorry for not replying to your last comment. I was here sometimes but had to leave before clicking this topic. I don’t often use emualtion, and mostly see these kind of error messages shared by others so I didn’t even had to debug emulation errors.
Unless you tried the exact same dockerfile with the same versions of the packages, I guess the reason could also be a changed package or changed hardware or kernel. And yes, an upgraded qemu. Which one caused this, I have no idea. The buildx developers could probably help you figure it out more easily. Or anyone who ever dealt with a similar error.. Or maybe you already solved it after 3 days.
mcandre
February 17, 2026, 11:11pm
5
Many buildx targets are still broken with these same qemu errors.
To work around this, I’m having to disable ppc64le, riscv64, and s390x, across all of my Docker image builds.
Dunno why they broke. Note that wine has similar errors when running in Docker on ARM Mac hosts.