This happens because QEMU is now stricter about its checking of the flags passed to clone() -- previously we would silently allow flags we couldn't support and create new threads with the wrong behaviour. Now we check and fail the clone() syscall if the requested behaviour is something we can't implement. Unfortunately we don't have any way to distinguish "guest program is asking for something odd that it doesn't really need" from "guest program is asking for something odd that it does need". So we err on the safe side and tell the guest we can't do it.
It's particularly unfortunate that the glibc implementation of posix_spawn() runs into this, though. ** Summary changed: - locale-gen dumps core run under arm-linux-user on x86-64 host + linux-user clone() can't handle glibc posix_spawn() (causes locale-gen to assert) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1673976 Title: linux-user clone() can't handle glibc posix_spawn() (causes locale-gen to assert) Status in QEMU: New Bug description: I'm running a command (locale-gen) inside of an armv7h chroot mounted on my x86_64 desktop by putting qemu-arm-static into /usr/bin/ of the chroot file system and I get a core dump. locale-gen Generating locales... en_US.UTF-8...localedef: ../sysdeps/unix/sysv/linux/spawni.c:360: __spawnix: Assertion `ec >= 0' failed. qemu: uncaught target signal 6 (Aborted) - core dumped /usr/bin/locale-gen: line 41: 34 Aborted (core dumped) localedef -i $input -c -f $charset -A /usr/share/locale/locale.alias $locale I've done this same thing successfully for years, but this breakage has appeared some time in the last 3 or so months. Possibly with the update to qemu version 2.8. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1673976/+subscriptions
