From: Christian Ehrhardt <2133188@bugs.launchpad.net>
To: qemu-devel@nongnu.org
Subject: [Bug 2133188] Re: [SRU] RISC-V vector state not restored by signal handler
Date: Wed, 21 Jan 2026 08:46:44 -0000 [thread overview]
Message-ID: <176898520458.3804449.6541613101442786110.malone@juju-98d295-prod-launchpad-3> (raw)
In-Reply-To: 176429928488.3164788.8613118615925713152.malonedeb@juju-98d295-prod-launchpad-2
Sadly this has gotten stuck upstream, there have been patches and people
willing to test but nothing concluded. We will have to check if/what we
can merge along 10.2 in the next few days or if it has to be a bug-fix
upload afterwards but hopefully before 26.04 release.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/2133188
Title:
[SRU] RISC-V vector state not restored by signal handler
Status in QEMU:
New
Status in qemu package in Ubuntu:
Confirmed
Status in qemu source package in Noble:
New
Status in qemu source package in Plucky:
Won't Fix
Status in qemu source package in Questing:
New
Status in qemu source package in Resolute:
Confirmed
Bug description:
# Title
qemu-user (qemu-riscv64-static): intermittent Illegal instruction in memset (vse64.v) when running cmake in riscv64 container (Ubuntu 26.04)
## Summary
While running cmake (and other build steps) inside a linux/riscv64 Ubuntu 26.04 container on an x86_64 host using qemu-user (qemu-riscv64-static) registered via binfmt_misc, cmake sometimes crashes with "Illegal instruction (core dumped)" or "died with signal 4". The illegal instruction is observed inside glibc's memset implementation at an instruction that uses RISC-V vector extension (vse64.v). The failure is intermittent (~50% reproducer rate). Using a scalar-only memset (libnovecmem.so via LD_PRELOAD) or running under gdb / enabling QEMU_STRACE significantly reduces or eliminates the failure, which strongly suggests a qemu-user/emulation bug (vector handling / code generation / state corruption), not a cmake bug.
## Affects
- qemu-user qemu-riscv64-static (as packaged in Ubuntu qemu 10.1.0+ds-5ubuntu3)
- Running in Docker container for riscv64 on x86_64 host via binfmt_misc qemu-user static interpreter
## Environment / Context
- Host CPU: x86_64 (Docker multiarch running qemu-user for riscv64)
- Host OS:multiple Ubuntu releases (22.04, 24.04, 25.10)
- Container image: ubuntu:26.04 for riscv64
- qemu package used:
- downloaded .deb from Launchpad: qemu-user_10.1.0+ds-5ubuntu3_amd64.deb and on several Debian qemu-user packages (qemu-user_10.2.0~rc1+ds-1, qemu-user_10.0.6+ds-0+deb13u2).
- copied qemu-riscv64 binary into /usr/bin/qemu-riscv64-static inside host and registered via /proc/sys/fs/binfmt_misc/register
- CMake version used inside container (bootstrap/build may use system-provided cmake binary): cmake 3.x (bootstrapping cmake while building also triggers crash)
- Reproduction frequency: intermittent, ~50% (can get large variance: several consecutive successes or failures)
- Observed behavior changes when: LD_PRELOAD libnovecmem.so (scalar memset) — almost completely avoids crash; running under gdb or enabling QEMU_STRACE also makes it much harder to reproduce.
## Full reproduction steps
1. On x86_64 host, fetch qemu-user .deb and extract the riscv static binary:
wget https://launchpad.net/ubuntu/+source/qemu/1:10.1.0+ds-5ubuntu3/+build/31393935/+files/qemu-user_10.1.0+ds-5ubuntu3_amd64.deb
dpkg-deb -x qemu-user_10.1.0+ds-5ubuntu3_amd64.deb qemu-user_10.1.0+ds-5ubuntu3_amd64
sudo cp qemu-user_10.1.0+ds-5ubuntu3_amd64/usr/bin/qemu-riscv64 /usr/bin/qemu-riscv64-static
2. Register qemu-riscv64 with binfmt_misc:
echo -1 > /proc/sys/fs/binfmt_misc/qemu-riscv64
echo ':qemu-riscv64:M:0:\x7f\x45\x4c\x46\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xf3\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin/qemu-riscv64-static:POCF' >/proc/sys/fs/binfmt_misc/register
3. Start riscv64 ubuntu container:
docker run --platform=linux/riscv64 --name ubuntu26 -itd ubuntu:26.04 bash
docker exec -it ubuntu26 bash -i
4. Inside container:
apt update
apt install -y build-essential cmake
5. Reproducer 1:
cmake --system-information
-> Often fails with:
bash: [15: 1 (255)] tcsetattr: Inappropriate ioctl for device
Illegal instruction (core dumped)
6. Reproducer 2 (minimal C project):
Create test_cmake/CMakeLists.txt:
cmake_minimum_required(VERSION 3.10)
project(HelloCMake C)
add_executable(hello main.c)
Create test_cmake/main.c:
#include <stdio.h>
int main() {
printf("Hello, CMake!\n");
return 0;
}
cd test_cmake
cmake .
-> Crash with:
-- Detecting C compiler ABI info
bash: line 1: 8489 Illegal instruction (core dumped) cmake .
7. Reproducer 3 (rebuild cmake from source inside container):
apt source cmake
cd cmake
apt-get build-dep .
dpkg-buildpackage -us -uc -b
-> Bootstrapping error:
Illegal instruction (core dumped)
Error when bootstrapping CMake:
Problem while running initial CMake
8. Observed crash location (from gdb/QEMU_STRACE when available):
- Illegal instruction is in memset@@GLIBC_2.27+0x52
- Faulting instruction: vse64.v v1,(a5) (RISC-V vector store of 64-bit elements)
## Workarounds
- LD_PRELOAD a scalar-only memset library (libnovecmem.so) to avoid glibc using vectorized memset.
- Run the failing process under gdb (slower) or enable QEMU_STRACE=1 — both make the failure much less likely.
Note: The same workload does not reproduce the crash when run under
qemu-system (full-system emulation). The issue appears specific to
qemu-user
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/2133188/+subscriptions
next prev parent reply other threads:[~2026-01-21 8:57 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <176429928488.3164788.8613118615925713152.malonedeb@juju-98d295-prod-launchpad-2>
2025-11-28 3:52 ` [Bug 2133188] Re: Illegal instruction in memset under qemu-user for riscv64 qianqiu
2025-11-28 8:58 ` Bug Watch Updater
2025-11-28 9:43 ` Heinrich Schuchardt
2025-11-28 17:08 ` Heinrich Schuchardt
2025-11-28 17:09 ` Launchpad Bug Tracker
2025-11-28 17:29 ` Heinrich Schuchardt
2025-11-28 18:04 ` Heinrich Schuchardt
2025-12-02 17:33 ` Heinrich Schuchardt
2025-12-02 18:05 ` Heinrich Schuchardt
2025-12-02 18:26 ` Heinrich Schuchardt
2025-12-03 9:48 ` Heinrich Schuchardt
2025-12-03 12:13 ` Heinrich Schuchardt
2025-12-03 12:51 ` Heinrich Schuchardt
2025-12-03 13:13 ` Heinrich Schuchardt
2025-12-03 13:18 ` Heinrich Schuchardt
2025-12-03 16:06 ` Heinrich Schuchardt
2025-12-03 16:07 ` Heinrich Schuchardt
2025-12-03 16:36 ` Heinrich Schuchardt
2025-12-03 17:33 ` qianqiu
2025-12-03 17:53 ` qianqiu
2025-12-03 18:01 ` Heinrich Schuchardt
2025-12-05 11:54 ` Heinrich Schuchardt
2025-12-05 14:36 ` Heinrich Schuchardt
2025-12-05 17:15 ` Heinrich Schuchardt
2025-12-07 15:36 ` Heinrich Schuchardt
2025-12-07 16:51 ` Heinrich Schuchardt
2025-12-07 16:57 ` Heinrich Schuchardt
2025-12-08 6:56 ` Heinrich Schuchardt
2025-12-08 7:00 ` Heinrich Schuchardt
2025-12-08 7:27 ` Heinrich Schuchardt
2025-12-08 7:39 ` [Bug 2133188] Re: [SRU] RISC-V vector state not restored by signal handler Heinrich Schuchardt
2025-12-08 11:03 ` Heinrich Schuchardt
2026-01-19 11:43 ` Utkarsh Gupta
2026-01-21 8:46 ` Christian Ehrhardt [this message]
2026-03-23 11:58 ` Heinrich Schuchardt
2026-03-23 12:12 ` Launchpad Bug Tracker
2026-03-23 12:54 ` Heinrich Schuchardt
2026-03-24 12:42 ` Jonas Jelten
2026-03-26 13:55 ` Hector CAO
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=176898520458.3804449.6541613101442786110.malone@juju-98d295-prod-launchpad-3 \
--to=2133188@bugs.launchpad.net \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox