8 files changed, 597 insertions, 0 deletions
diff --git a/results/classifier/118/none/109 b/results/classifier/118/none/109
new file mode 100644
index 00000000..54183892
--- /dev/null
+++ b/results/classifier/118/none/109
@@ -0,0 +1,31 @@
+device: 0.687
+architecture: 0.538
+network: 0.509
+permissions: 0.488
+performance: 0.450
+VMM: 0.427
+kernel: 0.421
+risc-v: 0.404
+semantic: 0.372
+KVM: 0.369
+PID: 0.362
+TCG: 0.349
+hypervisor: 0.342
+arm: 0.336
+mistranslation: 0.311
+boot: 0.307
+ppc: 0.286
+user-level: 0.275
+vnc: 0.270
+i386: 0.258
+x86: 0.240
+virtual: 0.232
+files: 0.224
+socket: 0.211
+debug: 0.204
+peripherals: 0.200
+assembly: 0.171
+graphic: 0.153
+register: 0.146
+
+Make Uninstall Rule Requested
diff --git a/results/classifier/118/none/1090604 b/results/classifier/118/none/1090604
new file mode 100644
index 00000000..141fe9d9
--- /dev/null
+++ b/results/classifier/118/none/1090604
@@ -0,0 +1,54 @@
+mistranslation: 0.644
+device: 0.638
+peripherals: 0.543
+network: 0.495
+virtual: 0.495
+semantic: 0.495
+graphic: 0.489
+ppc: 0.480
+socket: 0.470
+user-level: 0.459
+vnc: 0.432
+kernel: 0.411
+permissions: 0.406
+architecture: 0.397
+hypervisor: 0.391
+performance: 0.374
+files: 0.352
+risc-v: 0.351
+register: 0.330
+VMM: 0.328
+i386: 0.316
+x86: 0.310
+boot: 0.297
+TCG: 0.264
+PID: 0.259
+assembly: 0.227
+arm: 0.224
+debug: 0.222
+KVM: 0.190
+
+RFE: Implement support for SMBIOS Type 41 structures
+
+This was originally filed in Fedora bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=669955  
+
+"""
+Please extend the existing support for SMBIOS in qemu to add a capability to provide "Onboard Devices Extended Information" (Type 41). Not only is this replacing one of the existing types, but it also provides a mapping between devices and physical system chassis locations. But there is no physical chassis! Right. However, this doesn't mean you don't want to tell the guest OS which virtual (e.g. network) interface is which. You can do that, if you implement this extension that is already going into real hardware, and likely other VMs too.
+
+See also page 117 of the v2.7 of the SMBIOS spec.
+
+FWIW, VMware ESX and Workstation expose their PCI NICs in the PCI IRQ Routing Table.  Kind of odd the first time you see it with biosdevname, as your NIC becomes pci3#1, but that's "correct" from a BIOS perspective. :-)
+"""
+
+Hello, I'm intersted in this bug fix and have some free time. maybe I can do this bug-fix.
+
+I have sent a first patch around this: https://lists.nongnu.org/archive/html/qemu-devel/2021-03/msg09391.html
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/91
+
+
diff --git a/results/classifier/118/none/1090726 b/results/classifier/118/none/1090726
new file mode 100644
index 00000000..233596b1
--- /dev/null
+++ b/results/classifier/118/none/1090726
@@ -0,0 +1,85 @@
+graphic: 0.591
+arm: 0.567
+permissions: 0.523
+mistranslation: 0.493
+user-level: 0.466
+virtual: 0.457
+assembly: 0.456
+risc-v: 0.454
+device: 0.454
+hypervisor: 0.445
+register: 0.444
+semantic: 0.443
+PID: 0.442
+KVM: 0.441
+peripherals: 0.434
+TCG: 0.434
+debug: 0.398
+architecture: 0.398
+performance: 0.396
+vnc: 0.393
+ppc: 0.392
+VMM: 0.392
+socket: 0.387
+files: 0.376
+boot: 0.361
+kernel: 0.353
+network: 0.344
+x86: 0.266
+i386: 0.230
+
+qemu does not generate guest cpu topology properly
+
+Adding the option
+
+-smp 12,sockets=2,cores=6,threads=1
+
+exposes
+
+
+Machine (12GB)
+  Socket #0
+        L2 L#0 (512KB) + L1 L#0 (64KB) + Core L#0 + PU L#0 (P#0)
+        L2 L#1 (512KB) + L1 L#1 (64KB) + Core L#1 + PU L#1 (P#1)
+        L2 L#2 (512KB) + L1 L#2 (64KB) + Core L#2 + PU L#2 (P#2)
+        L2 L#3 (512KB) + L1 L#3 (64KB) + Core L#3 + PU L#3 (P#3)
+        L2 L#4 (512KB) + L1 L#4 (64KB) + Core L#4 + PU L#4 (P#4)
+        L2 L#5 (512KB) + L1 L#5 (64KB) + Core L#5 + PU L#5 (P#5)
+        L2 L#6 (512KB) + L1 L#6 (64KB) + Core L#6 + PU L#6 (P#6)
+        L2 L#7 (512KB) + L1 L#7 (64KB) + Core L#7 + PU L#7 (P#7)
+  Socket #1
+      L2 L#8 (512KB) + L1 L#8 (64KB) + Core L#8 + PU L#8 (P#8)
+      L2 L#9 (512KB) + L1 L#9 (64KB) + Core L#9 + PU L#9 (P#9)
+      L2 L#10 (512KB) + L1 L#10 (64KB) + Core L#10 + PU L#10 (P#10)
+      L2 L#11 (512KB) + L1 L#11 (64KB) + Core L#11 + PU L#11 (P#11)
+
+
+Rather than:
+
+Machine (12GB)
+  Socket #0
+        L2 L#0 (512KB) + L1 L#0 (64KB) + Core L#0 + PU L#0 (P#0)
+        L2 L#1 (512KB) + L1 L#1 (64KB) + Core L#1 + PU L#1 (P#1)
+        L2 L#2 (512KB) + L1 L#2 (64KB) + Core L#2 + PU L#2 (P#2)
+        L2 L#3 (512KB) + L1 L#3 (64KB) + Core L#3 + PU L#3 (P#3)
+        L2 L#4 (512KB) + L1 L#4 (64KB) + Core L#4 + PU L#4 (P#4)
+        L2 L#5 (512KB) + L1 L#5 (64KB) + Core L#5 + PU L#5 (P#5)
+  Socket #1
+        L2 L#6 (512KB) + L1 L#6 (64KB) + Core L#6 + PU L#6 (P#6)
+        L2 L#7 (512KB) + L1 L#7 (64KB) + Core L#7 + PU L#7 (P#7)
+        L2 L#8 (512KB) + L1 L#8 (64KB) + Core L#8 + PU L#8 (P#8)
+        L2 L#9 (512KB) + L1 L#9 (64KB) + Core L#9 + PU L#9 (P#9)
+        L2 L#10 (512KB) + L1 L#10 (64KB) + Core L#10 + PU L#10 (P#10)
+        L2 L#11 (512KB) + L1 L#11 (64KB) + Core L#11 + PU L#11 (P#11)
+
+
+Here is a cpuid dump from inside the guest and dump from more recent version of cpuid, in which you can see a bit more detail. The later contains data for a single CPU, because the others are the same.
+
+Reproducible on qemu 1.0 and 1.2. with guest os Fedora 17, Debian 6, Debian Squeeze and Windows 2008 R2.
+
+
+
+Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/none/1090837 b/results/classifier/118/none/1090837
new file mode 100644
index 00000000..c5e2fce8
--- /dev/null
+++ b/results/classifier/118/none/1090837
@@ -0,0 +1,68 @@
+user-level: 0.692
+debug: 0.690
+device: 0.683
+semantic: 0.642
+permissions: 0.615
+ppc: 0.599
+mistranslation: 0.580
+architecture: 0.565
+x86: 0.563
+performance: 0.531
+PID: 0.513
+socket: 0.502
+hypervisor: 0.500
+graphic: 0.499
+vnc: 0.493
+i386: 0.484
+network: 0.474
+risc-v: 0.470
+TCG: 0.462
+arm: 0.433
+register: 0.422
+kernel: 0.420
+boot: 0.388
+peripherals: 0.387
+files: 0.374
+VMM: 0.333
+KVM: 0.283
+assembly: 0.280
+virtual: 0.269
+
+Error in building Qemu-1.3.0 on Solaris 10 
+
+While trying to build Qemu on Oracle Solaris 10 (SPARC processor), I encountered the following error in the configure step:
+
+./configure --prefix=/usr/local/ --install=/usr/ucb/install
+./configure: bad substitution
+./configure: !: not found
+./configure: !: not found
+./configure: !: not found
+./configure: !: not found
+./configure: !: not found
+./configure: curl-config: not found
+./configure: curl-config: not found
+
+As the following bug report says: https://bugs.launchpad.net/qemu/+bug/636315, "sh" is hard-coded in the script. Can't the script be modified to accept a $SHELL argument to make use of bash or other shell during configure and make step?
+
+Are you using /bin/sh (broken) or /usr/xpg4/bin/sh (should work)?
+
+If I invoke /usr/xpg4/bin/sh from bash and then start the build process, will it be OK/ Or do I need to add /usr/xpg4/bin/sh to PATH? Does the patch mentioned in the referred bug need to be applied?
+
+Just using $SHELL inside configure would be insufficient if run via Solaris' sh.
+Using `bash ./configure ...` should've worked for v1.2 without patches, didn't test v1.3 on Sol10 yet.
+
+Whether the DTrace support scripts fully work on Solaris 10 is another issue.
+
+Until tomorrow, I can't report back as the Solaris 10 system is in my workplace. What I tried was to trigger ./configure from bash shell which produced the log above and aborted. As the title already says, I tried to build Qemu 1.3.0.
+
+P.S. If I already use bash shell to invoke the script, do I need to `bash ./configure ...` any more? 
+
+Yes, if you execute `./configure ...` the shell will execute the shebang line inside the script, which says /bin/sh and happens to be a really ancient version for backwards compatibility on Solaris.
+
+I did the following and it was a success:
+
+1. Added sh to path to override default /usr/bin/sh: PATH=/usr/xpg4/bin/sh:$PATH
+2. From bash: sh ./configure
+
+Closing, as there is a work-around according to comment #6
+
diff --git a/results/classifier/118/none/1093691 b/results/classifier/118/none/1093691
new file mode 100644
index 00000000..ddcdc114
--- /dev/null
+++ b/results/classifier/118/none/1093691
@@ -0,0 +1,103 @@
+graphic: 0.699
+TCG: 0.659
+register: 0.646
+virtual: 0.634
+semantic: 0.596
+mistranslation: 0.593
+assembly: 0.577
+files: 0.566
+network: 0.565
+peripherals: 0.562
+hypervisor: 0.557
+permissions: 0.543
+architecture: 0.542
+performance: 0.525
+risc-v: 0.520
+PID: 0.511
+arm: 0.510
+user-level: 0.510
+boot: 0.501
+socket: 0.492
+device: 0.492
+KVM: 0.485
+debug: 0.485
+ppc: 0.468
+VMM: 0.463
+kernel: 0.450
+vnc: 0.378
+x86: 0.338
+i386: 0.275
+
+QEMU build fails on OpenBSD/mips64
+
+Building QEMU 1.2.1 on OpenBSD/mips64 fails as follows although I believe QEMU was also broken with 1.1.x as well..
+
+cc -I/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/slirp -I. -I/usr/obj/ports/qemu-1.2.1/qemu-1.2.1 -I/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/fpu -I/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg -
+I/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/mips  -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmis
+sing-prototypes -fno-strict-aliasing -I/usr/local/include -I/usr/X11R6/include -Wno-redundant-decls -DTIME_MAX=INT_MAX  -Wendif-labels -Wmissing-include-dirs -Wnested-externs -Wf
+ormat-security -Wformat-y2k -Winit-self -Wold-style-definition -I/usr/local/include/libpng -DHAS_AUDIO -DHAS_AUDIO_CHOICE  -DTARGET_PHYS_ADDR_BITS=64 -I.. -I/usr/obj/ports/qemu-1
+.2.1/qemu-1.2.1/target-i386 -DNEED_CPU_H -I/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/include    -I/usr/local/include/libpng -pthread -I/usr/local/include/glib-2.0 -I/usr/local/lib/gli
+b-2.0/include -I/usr/local/include -MMD -MP -MT tcg/tcg.o -MF tcg/tcg.d -O2 -pipe -c -o tcg/tcg.o /usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg.c
+In file included from /usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg.c:50:
+/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h: In function 'tcg_gen_div_i64':
+/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1229: error: 'TCG_TARGET_HAS_div_i64' undeclared (first use in this function)
+/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1229: error: (Each undeclared identifier is reported only once
+/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1229: error: for each function it appears in.)
+/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1231: error: 'TCG_TARGET_HAS_div2_i64' undeclared (first use in this function)
+/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h: In function 'tcg_gen_rem_i64':
+/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1248: error: 'TCG_TARGET_HAS_div_i64' undeclared (first use in this function)
+/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1250: error: 'TCG_TARGET_HAS_div2_i64' undeclared (first use in this function)
+/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h: In function 'tcg_gen_divu_i64':
+/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1267: error: 'TCG_TARGET_HAS_div_i64' undeclared (first use in this function)                                                   
+/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1269: error: 'TCG_TARGET_HAS_div2_i64' undeclared (first use in this function)
+/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h: In function 'tcg_gen_remu_i64':
+/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1286: error: 'TCG_TARGET_HAS_div_i64' undeclared (first use in this function)                                                   
+/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1288: error: 'TCG_TARGET_HAS_div2_i64' undeclared (first use in this function)
+/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h: In function 'tcg_gen_ext8s_i64':
+/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1526: error: 'TCG_TARGET_HAS_ext8s_i64' undeclared (first use in this function)
+/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h: In function 'tcg_gen_ext16s_i64':
+/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1536: error: 'TCG_TARGET_HAS_ext16s_i64' undeclared (first use in this function)
+...
+
+Attached is the full build log.
+
+
+
+On Wed, Dec 26, 2012 at 09:55:38AM -0800, Richard Henderson wrote:
+> On 12/25/2012 01:12 PM, Brad Smith wrote:
+> > Public bug reported:
+> > 
+> > Building QEMU 1.2.1 on OpenBSD/mips64 fails as follows although I
+> > believe QEMU was also broken with 1.1.x as well..
+> ...
+> > In file included from /usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg.c:50:
+> > /usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h: In function 'tcg_gen_div_i64':
+> > /usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1229: error: 'TCG_TARGET_HAS_div_i64' undeclared (first use in this function)
+> 
+> The tcg/mips target only supports mips32.
+> 
+> In order to build on mips64 you'll need to use the interpreter backend,
+> configurable with --enable-tcg-interpreter.
+> 
+> We could be more clever and enable this by default for mips64...
+
+Strange. It was building with older releases and I'm fairly certain what
+was built actually ran Ok. Looking at the MIPS TCG code it looks as if
+there is some code in there to deal with 32-bit vs 64-bit MIPS.
+
+Anyway, if the MIPS TCG code does not officially support 64-bit MIPS
+then the build infrastructure should be fixed to not shoot people in
+the feet trying to build QEMU. The 32-bit SPARC support needs to be
+fixed too.
+
+-- 
+This message has been scanned for viruses and
+dangerous content by MailScanner, and is
+believed to be clean.
+
+
+
+Triaging old bug tickets ... does this problem still persist with the latest version of QEMU (currently version 2.9.0)?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/none/1095 b/results/classifier/118/none/1095
new file mode 100644
index 00000000..fa2aade3
--- /dev/null
+++ b/results/classifier/118/none/1095
@@ -0,0 +1,31 @@
+network: 0.767
+assembly: 0.720
+device: 0.685
+semantic: 0.675
+mistranslation: 0.535
+user-level: 0.467
+kernel: 0.432
+risc-v: 0.418
+register: 0.418
+architecture: 0.396
+boot: 0.378
+performance: 0.377
+peripherals: 0.364
+graphic: 0.358
+virtual: 0.338
+hypervisor: 0.325
+vnc: 0.324
+socket: 0.323
+i386: 0.314
+ppc: 0.310
+VMM: 0.302
+KVM: 0.293
+arm: 0.260
+permissions: 0.239
+PID: 0.238
+TCG: 0.211
+x86: 0.162
+files: 0.125
+debug: 0.120
+
+[QUESTION] What IF....
diff --git a/results/classifier/118/none/1098729 b/results/classifier/118/none/1098729
new file mode 100644
index 00000000..52529ce0
--- /dev/null
+++ b/results/classifier/118/none/1098729
@@ -0,0 +1,194 @@
+permissions: 0.785
+TCG: 0.775
+peripherals: 0.752
+risc-v: 0.751
+arm: 0.701
+assembly: 0.688
+debug: 0.685
+PID: 0.660
+device: 0.653
+boot: 0.646
+vnc: 0.643
+architecture: 0.642
+performance: 0.636
+semantic: 0.636
+graphic: 0.631
+kernel: 0.618
+ppc: 0.615
+register: 0.607
+user-level: 0.592
+KVM: 0.563
+socket: 0.558
+VMM: 0.547
+virtual: 0.546
+files: 0.532
+hypervisor: 0.498
+network: 0.446
+x86: 0.373
+i386: 0.357
+mistranslation: 0.302
+
+qemu-user-static for armhf: segfault in threaded code
+
+
+Currently running QEMU from git (fedf2de31023) and running the armhf version of qemu-user-static which I have renamed qemu-armhf-static to follow the naming convention used in Debian.
+
+The host systems is a Debian testing x86_64-linux and I have an Debian testing armhf chroot which I invoke using schroot.
+
+Majority of program in the armhf chroot run fine, but I'm getting qemu segfaults in multi-threaded programs.
+
+As an example, I've grabbed the threads demo program here:
+
+    https://computing.llnl.gov/tutorials/pthreads/samples/dotprod_mutex.c
+
+and changed NUMTHRDS from 4 to 10. I compile it as (same compile command on both x86_64 host and armhf guest):
+
+    gcc -Wall -lpthread dotprod_mutex.c -o dotprod_mutex
+
+When compiled for x86_64 host it runs perfectly and even under Valgrind displays no errors whatsoever.
+
+However, when I compile the program in my armhs chroot and run it it usually (but not always) segaults or hangs or crashes. Example output:
+
+
+    (armhf) $ ./dotprod_mutex
+    Thread 1 did 100000 to 200000:  mysum=100000.000000 global sum=100000.000000
+    Thread 0 did 0 to 100000:  mysum=100000.000000 global sum=200000.000000
+    TCG temporary leak before f6731ca0
+    qemu-arm-static: /home/erikd/Git/qemu-posix-timer-hacking/Upstream/tcg/tcg-op.h:2371:
+    tcg_gen_goto_tb: Assertion `(tcg_ctx.goto_tb_issue_mask & (1 << idx)) == 0' failed.
+
+
+    (armhf) $ ./dotprod_mutex
+    qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+    Segmentation fault
+
+    (armhf) $ ./dotprod_mutex
+    qemu-arm-static: /home/erikd/Git/qemu-posix-timer-hacking/Upstream/tcg/tcg.c:519:
+    tcg_temp_free_internal: Assertion `idx >= s->nb_globals && idx < s->nb_temps' failed.
+
+
+    (armhf) $ ./dotprod_mutex
+    Thread 1 did 100000 to 200000:  mysum=100000.000000 global sum=100000.000000
+    qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+    Segmentation fault
+
+I can also comple a purely static version of the test program in the armhf chroot using:
+
+    gcc -Wall -static -pthread dotprod_mutex.c -o dotprod-mutex-static
+
+and then run it simply using:
+
+    qemu-arm-static dotprod-mutex-static
+
+which fails just like it does in the chroot.
+
+Begining to think this is memory corruption because of the number of different failure modes. In addition to the crashes in the initial report I have also seen the following:
+
+
+    qemu: uncaught target signal 4 (Illegal instruction) - core dumped
+
+    More temporaries freed than allocated!
+    TCG temporary leak before 0001d1dc
+    
+    qemu-arm-static: /home/erikd/Git/qemu-pthread-hacking/tcg/tcg.c:1888: tcg_reg_alloc_op:
+    Assertion `ts->val_type == 1' failed.
+
+    /home/erikd/Git/qemu-pthread-hacking/tcg/tcg.c:149: tcg fatal error
+
+
+What's the best way to debug the qemu user space emulation? I read this:
+
+    http://wiki.qemu.org/Documentation/Debugging
+
+but that seems to mainly refer to the qemu machine emulation.
+
+I added -ggdb to QEMU_CFLAGS in config-host.mak so it builds with debug symbols but gdb still doesn't provide any useful information beyond the following:
+
+    Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
+    [New Thread 0x7ffefdb6b700 (LWP 11210)]
+    [New Thread 0x7ffefdaf5700 (LWP 11211)]
+    [New Thread 0x7ffefda7f700 (LWP 11212)]
+    [New Thread 0x7ffefda09700 (LWP 11213)]
+    [New Thread 0x7ffefd993700 (LWP 11214)]
+
+    Program received signal SIGSEGV, Segmentation fault.
+    [Switching to Thread 0x7ffefdaf5700 (LWP 11211)]
+    0x0000000060363b58 in static_code_gen_buffer ()
+    (gdb) bt
+    #0  0x0000000060363b58 in static_code_gen_buffer ()
+    #1  0x00000000f50ba518 in ?? ()
+    #2  0x00000000624a9360 in ?? ()
+    #3  0x00007ffefdaf4b80 in ?? ()
+    #4  0x326cebdf4a8e4700 in ?? ()
+    #5  0x00007ffe00000000 in ?? ()
+    #6  0x0000000000000000 in ?? ()
+
+and valgrind doesn't help either.
+
+Yes, multithreaded guests are liable to crash; where they work they generally work more by luck than design. There is some discussion in LP:668799 of one of the known problems (whose symptoms are usually crashes or hangs).
+
+
+At the top of function  cpu_unlink_tb() in translate-all.c:
+
+  /* FIXME: TB unchaining isn't SMP safe.  For now just ignore the
+       problem and hope the cpu will stop of its own accord.  For userspace
+       emulation this often isn't actually as bad as it sounds.  Often
+       signals are used primarily to interrupt blocking syscalls.  */
+
+
+The class of bugs exemplified by the symptoms described here are those where the multithreaded guest program causes QEMU to misbehave because we are sharing the code-translation globals (eg the generated code buffer) between multiple threads and they trod on each others' toes.
+
+(The race described in the comment in cpu_unlink_tb() has been fixed under LP:668799.)
+
+I also experimented the bug.
+It may SIGSEGV or hang. Or it may work, very rarely.
+
+But I cannot reproduce it at all if change my app to stay on a single CPU:
+
+int
+main(int argc, char * argv[] )
+{
+
+#ifdef QEMU
+    cpu_set_t cpuSet;
+    CPU_ZERO(&cpuSet);
+    CPU_SET(0,&cpuSet);
+    if (sched_setaffinity(getpid(), sizeof(cpu_set_t), &cpuSet) !=0)
+    	cerr << "sched_setaffinity failed" << endl;
+#endif /* QEMU */
+
+./build/buildd/qemu-linaro-1.5.0-2013.06/tcg/tcg.c:149: tcg fatal error
+/build/buildd/qemu-linaro-1.5.0-2013.06/tcg/tcg.c:149: tcg fatal error
+
+same for me
+
+Same problem for me when executing msgmerge in qemu-arm-static.
+
+https://launchpadlibrarian.net/181070813/buildlog_ubuntu-utopic-armhf.hedgewars_0.9.21~alpha~7716~ubuntu14.10.1_FAILEDTOBUILD.txt.gz
+
+this started happening after the new deploy of trusty in buildds
+
+Also happening when manually built from the 2.1.2 release codebase.  In my case it impacts the llvm-3.5.0 "make check" testsuite running an an armhf-emulated chroot--it immediately gets SIGSEGV and SIGILL as soon as it starts running tests.
+
+I cannot make dotprod_mutex.c to crash with the current master (git 8ffe756d). I've tried both linux-arm and linux-arm-static, the latter running under chroot.
+
+I've tried on three different machines, and have tested with different thread counts: 4, 10, 16, 64 (one of the machines has 64 cores).
+I completed 1000 successive runs on each.
+
+Can you please retest on the current master? I certainly could trigger the bug on the qemu-arm-static that is packaged with Ubuntu 14.04, so it is possible that since then changes in qemu have at least made it harder to trigger the bug.
+
+
+
+I can confirm that building QEMU 2.5.0 from source, all the multi-thread issues seem to be fixed.
+
+Specifically, the mentioned dotprod_mutex.c example, even when modified to use 100 threads, is always running in the qemu-arm User mode emulator.
+
+Tested in Ubuntu 14.04 x86_64, with all the updates installed.
+
+Note that instead the QEMU 2.0.0 from the Ubuntu 14.04 repository is having issues even when using workarounds like running it with "taskset 0x1" to force the execution to a single CPU.
+
+
+
+We think we've fixed the multithreading issues in QEMU linux-user (in particular the test case that started this bug report works). If there are still problems with a QEMU version later than 2.10, please open fresh bug reports for specific guest programs that fail, giving detailed how-to-reproduce instructions.
+
+
diff --git a/results/classifier/118/none/1099 b/results/classifier/118/none/1099
new file mode 100644
index 00000000..8f90bcf2
--- /dev/null
+++ b/results/classifier/118/none/1099
@@ -0,0 +1,31 @@
+device: 0.692
+arm: 0.625
+network: 0.551
+files: 0.540
+performance: 0.515
+register: 0.506
+risc-v: 0.482
+PID: 0.448
+architecture: 0.443
+boot: 0.416
+debug: 0.383
+peripherals: 0.380
+socket: 0.369
+permissions: 0.331
+VMM: 0.323
+ppc: 0.321
+virtual: 0.232
+TCG: 0.222
+i386: 0.220
+kernel: 0.210
+vnc: 0.205
+hypervisor: 0.205
+graphic: 0.199
+x86: 0.140
+semantic: 0.137
+KVM: 0.127
+mistranslation: 0.116
+assembly: 0.114
+user-level: 0.095
+
+zlib: Concurrent modification is unsafe