1 files changed, 165 insertions, 0 deletions
diff --git a/results/classifier/118/review/1891748 b/results/classifier/118/review/1891748
new file mode 100644
index 000000000..dcb945349
--- /dev/null
+++ b/results/classifier/118/review/1891748
@@ -0,0 +1,165 @@
+mistranslation: 0.866
+semantic: 0.864
+peripherals: 0.858
+risc-v: 0.858
+debug: 0.839
+user-level: 0.825
+performance: 0.815
+boot: 0.811
+device: 0.807
+arm: 0.806
+VMM: 0.783
+PID: 0.774
+kernel: 0.764
+assembly: 0.756
+socket: 0.754
+KVM: 0.753
+architecture: 0.745
+hypervisor: 0.728
+graphic: 0.727
+register: 0.722
+ppc: 0.719
+virtual: 0.716
+files: 0.709
+permissions: 0.686
+vnc: 0.683
+TCG: 0.631
+network: 0.589
+x86: 0.571
+i386: 0.386
+--------------------
+arm: 0.984
+virtual: 0.574
+user-level: 0.207
+hypervisor: 0.165
+files: 0.071
+debug: 0.020
+register: 0.011
+TCG: 0.006
+permissions: 0.006
+PID: 0.005
+kernel: 0.004
+device: 0.004
+network: 0.003
+performance: 0.003
+socket: 0.002
+boot: 0.002
+semantic: 0.002
+VMM: 0.001
+architecture: 0.001
+vnc: 0.001
+peripherals: 0.001
+assembly: 0.001
+ppc: 0.001
+risc-v: 0.001
+graphic: 0.001
+x86: 0.000
+KVM: 0.000
+i386: 0.000
+mistranslation: 0.000
+
+qemu-arm-static 5.1 can't run gcc
+
+Issue discovered while trying to build pikvm (1)
+
+Long story short: when using qemu-arm-static 5.1, gcc exits whith message:
+
+Allocating guest commpage: Operation not permitted
+
+
+when using qemu-arm-static v5.0, gcc "works"
+
+Steps to reproduce will follow 
+
+(1)  https://github.com/pikvm/pikvm/blob/master/pages/building_os.md
+
+Steps to reproduce
+
+1. Download and extract attached tarball.
+
+$ make # will build the docker container
+
+$ make run # will enter the container
+
+# once in the container, run 
+
+# /qemu-arm-static-50 /bin/bash /runme.sh
+
+
+
+
+Additional info,
+
+error message text ( "Allocating guest commpage" ) found in this commit:
+
+
+https://fossies.org/diffs/qemu/5.0.0_vs_5.1.0-rc0/linux-user/elfload.c-diff.html
+
+Anyone? Seriously, the problem really exists and we even made a case that reproduces it. Someone please take a look at this.
+
+Plz take a look at this issue please.
+
+This has been fixed in mainline, probably commit
+8ef618859c379fdce81c91bc93e0574e36ea76ff.
+
+
+Released with QEMU v5.2.0.
+
+I'm still seeing this with qemu 5.2.0
+
+armv7a-softfp-linux-gnueabi-gcc -O2 -pipe -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=softfp   -Wl,-O1 -Wl,--as-needed  glibc-test.c   -o glibc-test
+Allocating guest commpage: Operation not permitted
+
+
+
+$ qemu-arm --version
+qemu-arm version 5.2.0 (Debian 1:5.2+dfsg-6)
+Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers
+
+I’m seeing this error on a totally different file:
+
+I’ve made a short test program (hello world-ish) and compiled it with the OpenWrt toolchain but added -static so I can run it on the host using qemu-user-arm:
+
+$ STAGING_DIR=$PWD/staging_dir PATH=staging_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-7.5.0_musl_eabi/bin:$PATH arm-openwrt-linux-muslgnueabi-gcc -Os -pipe -g3 -fno-caller-saves -fno-plt -fhonour-copts -mfloat-abi=hard -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -static x.c
+$ ./a.out 
+Allocating guest commpage: Operation not permitted
+
+
+Heh, even if I omit -static …
+
+It works with sudo, but that can’t be the fix…
+
+Could you check the result of "sysctl vm.mmap_min_addr"
+
+65536 is the value that works for me.
+
+@aurent-vivier Checked.
+This value does not affect the bug, after changing it, I still get an error.
+
+Anyone?
+
+I've been unable to replicate the crash with any of the instructions here. Certainly all the statically compiled unit tests work and I've just done a build of QEMU in an emulated Debian Buster (Armel) docker image.
+
+Okay, what do you think this problem might be related to? I'm glad your tests are working, but I'm definitely not the only one with this problem.
+
+I think the output of "sysctl vm" could help to identify which parameter is involved in the problem. You can also compare the output of "sudo sysctl vm" and "sysctl vm"
+
+In my case, sudo does not affect this bug. My output in attachements.
+
+Sup?
+
+Okay, it was found experimentally that the problem is reproduced if vm.mmap_min_addr is greater than 53249. If from 0 to 53249 - everything works. What can this be related to?
+
+I mean [0...52348] is working.
+
+Sorry, an error in previous message.
+
+Fixed and detailed diagnostics:
+
+[0    ...  53248] - working
+[53249 ... 61440] - Cannot allocate memory
+[61441 ... 65536 and higher] - Operation not permitted
+
+Can confirm this bug on fresh Linux Arch and Debian Linux installation.
+I need just nothing to reproduce it: Just install fresh arch and do steps described in comment #1
+