Okay, I'm trying to classify this bug report under one of the given categories: instruction, syscall, or runtime. Let me go through each step carefully. First, the problem is happening in a CentOS 7 arm64 container running on an Ubuntu 22 amd64 host using Docker. The user runs a command that seems to hang and take over the CPU. Specifically, they're executing `LD_DEBUG=all /lib64/ld-2.17.so --list /usr/bin/true &`, which starts a background process with PID 74. They check the process status and see that this process is using a lot of CPU time. Looking at the additional information provided: 1. The issue isn't present on an Ubuntu 20.04 host doing the same thing. 2. On an AWS arm64 native machine, without QEMU binfmt, the container works fine. 3. They have multiple images built daily, but only this CentOS 7 arm64 one has the problem. 4. Using trace-cmd didn't help because it couldn't enable KVM events. 5. Built qemu-8.1.0-rc3 but thinks the old binfmt might still be in use. The issue seems to relate to running an arm64 container on amd64 hardware, which requires QEMU's binfmt support for emulation. The process is getting stuck and consuming CPU, suggesting a runtime problem with how QEMU or the binfmt handling is working. Now, considering the categories: - **Instruction**: This would involve a specific faulty instruction in the code causing issues. I don't see evidence of that here; it's more about execution behavior. - **Syscall**: If there were issues with system calls (like read, write, etc.), but the problem seems to be broader than just one syscall. - **Runtime**: This covers general runtime errors or issues during execution, which fits because the process hangs and uses CPU excessively. Since the problem occurs at runtime when using QEMU's binfmt to execute arm64 code on amd64, it's likely a runtime issue. It might be related to how QEMU handles certain instructions or processes in this environment. runtime