diff options
Diffstat (limited to 'results/classifier/118/unknown/1319100')
| -rw-r--r-- | results/classifier/118/unknown/1319100 | 165 |
1 files changed, 165 insertions, 0 deletions
diff --git a/results/classifier/118/unknown/1319100 b/results/classifier/118/unknown/1319100 new file mode 100644 index 000000000..d04e5c2e6 --- /dev/null +++ b/results/classifier/118/unknown/1319100 @@ -0,0 +1,165 @@ +peripherals: 0.895 +permissions: 0.880 +user-level: 0.879 +risc-v: 0.874 +mistranslation: 0.865 +TCG: 0.856 +debug: 0.848 +register: 0.842 +KVM: 0.842 +assembly: 0.839 +x86: 0.830 +hypervisor: 0.826 +device: 0.820 +architecture: 0.818 +vnc: 0.815 +VMM: 0.806 +performance: 0.802 +socket: 0.800 +arm: 0.797 +kernel: 0.795 +semantic: 0.793 +graphic: 0.789 +network: 0.779 +ppc: 0.774 +virtual: 0.765 +PID: 0.761 +boot: 0.761 +i386: 0.734 +files: 0.729 + +qemu-arm-static bug in signal handling causes mono and java to hang + +Note, this bug is already reported to debian, but it seems to also affect the upstream code. +https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748043 + +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=mono-runtime --foreign --arch=armel "wheezy" "mono-test" "http://ftp.de.debian.org//debian" +cp /usr/bin/qemu-arm-static mono-test/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/debootstrap --second-stage +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/mono/4.0/gacutil.exe + +This will block on a futex: + +--8<-- +18663 sched_yield(0,0,2582980,0,0,2582928) = 0 +18663 clock_gettime(1,-150996384,2,1,2585016,2585600) = 0 +18663 tgkill(18663,18664,30,18664,30,-161951744) = 0 +18663 futex(0x00293774,FUTEX_PRIVATE_FLAG|FUTEX_WAIT,0,NULL,NULL,0) +--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/mono/4.0/gacutil.exe + +--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_REQUEUE_PRIVATE, 1, 2147483647, 0x94da20, 24) = 3 +14078 <... futex resumed> ) = 0 +14078 futex(0x94da20, FUTEX_WAKE_PRIVATE, 1) = 1 +14077 <... futex resumed> ) = 0 +14075 futex(0x94d9a4, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x94da20, 26 <unfinished ...> +--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/mono/MonoGetAssemblyName.exe /usr/lib/cli/nunit.core-2.6/nunit.core.dll) + +Obviously the same as described in: +http://lists.opensuse.org/opensuse-arm/2011-12/msg00000.html +is happening here. + +There is an openSuSE patch against qemu: +https://build.opensuse.org/package/view_file/Virtualization:Qemu/qemu/0002-XXX-work-around-SA_RESTART-race-wit.patch?expand=1 + +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. + +On 13 May 2014 16:56, manut <email address hidden> wrote: +> 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=mono-runtime --foreign --arch=armel "wheezy" "mono-test" "http://ftp.de.debian.org//debian" +> cp /usr/bin/qemu-arm-static mono-test/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/debootstrap --second-stage +> 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/mono/4.0/gacutil.exe +> +> This will block on a futex: +> +> --8<-- +> 18663 sched_yield(0,0,2582980,0,0,2582928) = 0 +> 18663 clock_gettime(1,-150996384,2,1,2585016,2585600) = 0 +> 18663 tgkill(18663,18664,30,18664,30,-161951744) = 0 +> 18663 futex(0x00293774,FUTEX_PRIVATE_FLAG|FUTEX_WAIT,0,NULL,NULL,0) +> --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: +https://bugs.launchpad.net/qemu/+bug/955379 + +> There is an openSuSE patch against qemu: +> https://build.opensuse.org/package/view_file/Virtualization:Qemu/qemu/0002-XXX-work-around-SA_RESTART-race-wit.patch?expand=1 + +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 + + +Status changed to 'Confirmed' because the bug affects multiple users. + +also causes problems with java. + +Recent changes to QEMU's handling of signals fix this hang trying to run mono under QEMU; they should be out in QEMU 2.7. + + +Did this fix end up making it into QEMU 2.7? + +Yes it did. + + +Fixed in 2.7 and thereby >=Zesty + +I can't guess very well how important this would be for an SRU (or not), leaving that up for user feedback to be decided. + |