1 files changed, 73 insertions, 0 deletions
diff --git a/results/classifier/118/performance/1426593 b/results/classifier/118/performance/1426593
new file mode 100644
index 000000000..6892ce106
--- /dev/null
+++ b/results/classifier/118/performance/1426593
@@ -0,0 +1,73 @@
+performance: 0.862
+architecture: 0.861
+user-level: 0.853
+hypervisor: 0.844
+graphic: 0.844
+semantic: 0.798
+permissions: 0.780
+mistranslation: 0.780
+kernel: 0.747
+device: 0.731
+ppc: 0.728
+arm: 0.715
+PID: 0.686
+register: 0.643
+debug: 0.640
+peripherals: 0.604
+risc-v: 0.572
+files: 0.568
+VMM: 0.565
+network: 0.561
+assembly: 0.558
+vnc: 0.555
+socket: 0.551
+x86: 0.526
+TCG: 0.525
+i386: 0.520
+boot: 0.509
+KVM: 0.463
+virtual: 0.413
+
+linux-user: doesn't handle guest setting its memory ulimit very small
+
+using the latest build from git (hash 041ccc922ee474693a2869d4e3b59e920c739bc0 ) and all older versions i have tested.
+i am using an amd64 host with an arm chroot using "qemu-user arm cortex-a8" cpu emulation to run it
+
+building coreutils hangs on "checking whether printf survives out-of-memory conditions"
+
+i have not had time to dig into the build system to isolate the test yet, there were old reports of this bug but i can no longer find them on google.
+
+On 28 February 2015 at 09:01, aaron <email address hidden> wrote:
+> Public bug reported:
+>
+> using the latest build from git (hash 041ccc922ee474693a2869d4e3b59e920c739bc0 ) and all older versions i have tested.
+> i am using an amd64 host with an arm chroot using "qemu-user arm cortex-a8" cpu emulation to run it
+>
+> building coreutils hangs on "checking whether printf survives out-of-
+> memory conditions"
+>
+> i have not had time to dig into the build system to isolate the test
+> yet, there were old reports of this bug but i can no longer find them on
+> google.
+
+Yes, I seem to recall looking at this one before. QEMU's linux-user
+code doesn't try to isolate the guest's memory allocations from
+its own allocations. So if the guest sets the memory limit to
+something very small then the chances are good that this will
+result in one of QEMU's internal allocations failing, and then
+QEMU will probably exit with an error or possibly crash or hang
+(some of our error handling on these allocations is not good).
+
+For this kind of test to work correctly we would need to fake
+the memory limit syscalls rather than just passing them through
+to the host, and then also do all the accounting to track how
+much memory the guest has allocated. That's a fair amount of
+work so it's unlikely this bug will be fixed unless somebody
+who cares about it submits patches, I'm afraid.
+
+-- PMM
+
+
+I've just noticed that this is a duplicate of bug 1163034 (gnutls uses a very similar configure test), so I'm going to mark this one as a dup of that one, since it's older.
+
+