add 18th iteration of classifier

1 files changed, 86 insertions, 0 deletions

diff --git a/results/classifier/118/all/1815911 b/results/classifier/118/all/1815911
new file mode 100644
index 000000000..6a8740e52
--- /dev/null
+++ b/results/classifier/118/all/1815911
@@ -0,0 +1,86 @@
+peripherals: 0.986
+permissions: 0.986
+register: 0.983
+semantic: 0.983
+mistranslation: 0.982
+graphic: 0.982
+architecture: 0.981
+assembly: 0.980
+device: 0.980
+performance: 0.979
+risc-v: 0.979
+debug: 0.979
+boot: 0.977
+socket: 0.976
+arm: 0.974
+files: 0.971
+virtual: 0.970
+hypervisor: 0.970
+user-level: 0.970
+VMM: 0.970
+PID: 0.969
+vnc: 0.966
+TCG: 0.963
+network: 0.963
+kernel: 0.962
+KVM: 0.959
+ppc: 0.957
+x86: 0.937
+i386: 0.887
+
+aptitude crashes qemu-m68k with handle_cpu_signal received signal outside vCPU context
+
+When building a package with sbuild on Debian, sbuild can use aptitude to resolve dependencies.
+
+Recently, some changes introduced to aptitude or related packages cause qemu to crash:
+
+(sid-m68k-sbuild)root@nofan:/# aptitude -y --without-recommends -o Dpkg::Options::=--force-confold -o Aptitude::CmdLine::Ignore-Trust-Violations=false -o Aptitude::ProblemResolver::StepScore=100 -o Aptitude::ProblemResolver::SolutionCost="safety, priority, non-default-versions" -o Aptitude::ProblemResolver::Hints::KeepDummy="reject sbuild-build-depends-core-dummy :UNINST" -o Aptitude::ProblemResolver::Keep-All-Level=55000 -o Aptitude::ProblemResolver::Remove-Essential-Level=maximum install vim
+Warning: Invalid locale (please review locale settings, this might lead to problems later):
+  locale::facet::_S_create_c_locale name not valid
+The following NEW packages will be installed:
+  libgpm2{a} vim vim-common{a} vim-runtime{a} xxd{a} 
+0 packages upgraded, 5 newly installed, 0 to remove and 1 not upgraded.
+Need to get 7225 kB/7260 kB of archives. After unpacking 33.5 MB will be used.
+qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x6019d1bf
+qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x601b64ab
+Segmentation fault
+(sid-m68k-sbuild)root@nofan:/#
+
+The crash does not reproduce on real hardware running Debian unstable.
+
+It seems it crashes during futex syscall:
+
+...
+[pid     4] getpid()                    = 4
+[pid     4] tgkill(4, 24, SIGRT_1)      = 0
+[pid    24] <... futex resumed> )       = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
+[pid    24] --- SIGRT_1 {si_signo=SIGRT_1, si_code=SI_TKILL, si_pid=4, si_uid=0} ---
+[pid     4] futex(0x7f77abb4f610, FUTEX_WAIT_PRIVATE, 16777216, NULL <unfinished ...>
+[pid    24] getpid()                    = 4
+[pid    24] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x10} ---
+...
+
+On 2/15/19 1:47 PM, Laurent Vivier wrote:
+> It seems it crashes during futex syscall:
+> 
+> ...
+> [pid     4] getpid()                    = 4
+> [pid     4] tgkill(4, 24, SIGRT_1)      = 0
+> [pid    24] <... futex resumed> )       = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
+> [pid    24] --- SIGRT_1 {si_signo=SIGRT_1, si_code=SI_TKILL, si_pid=4, si_uid=0} ---
+> [pid     4] futex(0x7f77abb4f610, FUTEX_WAIT_PRIVATE, 16777216, NULL <unfinished ...>
+> [pid    24] getpid()                    = 4
+> [pid    24] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x10} ---
+> ...
+
+The crash also reproduces with qemu-sh4, so it's not specific to m68k.
+
+
+I think this is probably a duplicate of bug #1594394, in which case it seems to be fixed in 5.0.0+.
+
+John, can you still reproduce it with the latest version of QEMU?
+
+Just verified it with a very recently compiled version of QEMU from git master and, indeed, the bug seems to be fixed as I can no longer reproduce the crash. The command executes correctly.
+
+I guess it's safe to mark this as fixed.
+