qemu-arm-static bug in signal handling causes mono and java to hang
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
QEMU |
Fix Released
|
Undecided
|
Unassigned | ||
qemu-kvm (Debian) |
Fix Released
|
Unknown
|
|||
qemu-kvm (Ubuntu) |
Fix Released
|
Wishlist
|
Unassigned |
Bug Description
Note, this bug is already reported to debian, but it seems to also affect the upstream code.
https:/
running mono in a chroot environment with qemu-user-static is not posible
because at least one signal used during termination of mono is routed to the
host.
This can be reproduced by:
debootstrap --include=
cp /usr/bin/
mount -t proc none mono-test/proc
mount -o bind /dev mono-test/dev
mount -o bind /sys mono-test/sys
chroot mono-test
../debootstrap/
exit
mount -t proc none mono-test/proc
mount -o bind /sys mono-test/sys
chroot mono-test
QEMU_STRACE=1 /usr/bin/mono /usr/lib/
This will block on a futex:
--8<--
18663 sched_yield(
18663 clock_gettime(
18663 tgkill(
18663 futex(0x0029377
--8<--
If you use mono within strace on a native x86 box you can see, that signals
between threads are used during termination:
strace -f -o log.txt /usr/bin/mono /usr/lib/
--8<--
14075 sched_yield() = 0
14075 tgkill(14075, 14083, SIGPWR) = 0
14075 futex(0x983f00, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
14083 <... futex resumed> ) = ? ERESTARTSYS (To be restarted)
14083 --- SIGPWR (Power failure) @ 0 (0) ---
14083 futex(0x983f00, FUTEX_WAKE_PRIVATE, 1) = 1
14075 <... futex resumed> ) = 0
14083 rt_sigsuspend(~[INT QUIT ABRT TERM XCPU RTMIN RT_1] <unfinished ...>
14075 futex(0x94d9a4, FUTEX_CMP_
14078 <... futex resumed> ) = 0
14078 futex(0x94da20, FUTEX_WAKE_PRIVATE, 1) = 1
14077 <... futex resumed> ) = 0
14075 futex(0x94d9a4, FUTEX_CMP_
--8<--
This also blocks the installation of libnunit2.6-cil within a armel chroot,
because it uses mono in its postinst script.
E.g. (/usr/bin/mono /usr/share/
Obviously the same as described in:
http://
is happening here.
There is an openSuSE patch against qemu:
https:/
This patch also applies against qemu from backports-wheezy and resolves this
issue.
As it seems, that this issue is not Debian specific i will also report it to
the qemu project and reference this bug report.
tags: | added: trusty |
affects: | qemu → qemu-kvm (Ubuntu) |
Changed in qemu-kvm (Ubuntu): | |
status: | New → Confirmed |
Changed in qemu-kvm (Debian): | |
status: | Unknown → Confirmed |
Changed in qemu-kvm (Ubuntu): | |
status: | New → Confirmed |
importance: | Undecided → Wishlist |
Changed in qemu-kvm (Debian): | |
status: | Confirmed → Fix Released |
On 13 May 2014 16:56, manut <email address hidden> wrote: mono-runtime --foreign --arch=armel "wheezy" "mono-test" "http:// ftp.de. debian. org//debian" qemu-arm- static mono-test/usr/bin debootstrap --second-stage mono/4. 0/gacutil. exe 0,0,2582980, 0,0,2582928) = 0 1,-150996384, 2,1,2585016, 2585600) = 0 18663,18664, 30,18664, 30,-161951744) = 0 4,FUTEX_ PRIVATE_ FLAG|FUTEX_ WAIT,0, NULL,NULL, 0)
> running mono in a chroot environment with qemu-user-static is not posible
> because at least one signal used during termination of mono is routed to the
> host.
>
> This can be reproduced by:
> debootstrap --include=
> cp /usr/bin/
> mount -t proc none mono-test/proc
> mount -o bind /dev mono-test/dev
> mount -o bind /sys mono-test/sys
> chroot mono-test
> ../debootstrap/
> exit
> mount -t proc none mono-test/proc
> mount -o bind /sys mono-test/sys
> chroot mono-test
> QEMU_STRACE=1 /usr/bin/mono /usr/lib/
>
> This will block on a futex:
>
> --8<--
> 18663 sched_yield(
> 18663 clock_gettime(
> 18663 tgkill(
> 18663 futex(0x0029377
> --8<--
>
> If you use mono within strace on a native x86 box you can see, that signals
> between threads are used during termination:
Multithreaded guest process are unreliable under qemu
linux-user mode anyway, even ignoring the signal handling
related races here.
See also: /bugs.launchpad .net/qemu/ +bug/955379
https:/
> There is an openSuSE patch against qemu: /build. opensuse. org/package/ view_file/ Virtualization: Qemu/qemu/ 0002-XXX- work-around- SA_RESTART- race-wit. patch?expand= 1
> https:/
This patch is a very hacky bandaid papering over the
real problem. It is not suitable for upstream (and
personally I wouldn't ship it in a distro either :-)).
thanks
-- PMM