1 files changed, 81 insertions, 0 deletions
diff --git a/results/classifier/118/graphic/1869782 b/results/classifier/118/graphic/1869782
new file mode 100644
index 000000000..802fb98bb
--- /dev/null
+++ b/results/classifier/118/graphic/1869782
@@ -0,0 +1,81 @@
+graphic: 0.862
+arm: 0.737
+kernel: 0.718
+architecture: 0.694
+device: 0.653
+ppc: 0.630
+semantic: 0.543
+vnc: 0.531
+register: 0.519
+virtual: 0.512
+performance: 0.509
+socket: 0.490
+user-level: 0.488
+hypervisor: 0.476
+permissions: 0.409
+PID: 0.387
+risc-v: 0.346
+files: 0.345
+peripherals: 0.341
+network: 0.337
+mistranslation: 0.319
+debug: 0.313
+assembly: 0.301
+TCG: 0.299
+x86: 0.282
+VMM: 0.277
+boot: 0.276
+i386: 0.242
+KVM: 0.198
+
+qemu-arm-static crashes "segmentation fault" when running "svn checkout"
+
+I'm not actually sure how far I can help as I so far failed to reproduce the issue on my local VM but I get it on Travis CI every time. I even went through the hassle of hacking a Debian repository into their Ubuntu Bionic VM to get qemu 4.2 as I hoped a new version could fix this.
+
+Here is where the error occured: https://travis-ci.com/github/VDR4Arch/vdr4arch/jobs/309106220#L5420
+
+I don't get this error with an armv7h chroot.
+
+Maybe now I'll just try to remove all uses of svn in my build scripts...
+
+Is it actually a viable solution to cross-build with qemu? I'm starting to doubt it...
+
+Would it help if I manage to get this core dump out of Travis somehow (maybe make Travis push it to some GIT or upload it to my webserver)?
+
+Is there a way that you can confirm that the QEMU being used to execute the binaries in the chroot really really is the new one you think it is? In this kind of setup where there's a chroot and somebody else's CI system and so on it can be quite easy for eg the new qemu binary not to get copied into the chroot so it's using the old version still, or whatever. So being able to rule that kind of possibility out would be helpful.
+
+
+I could run an "qemu... --version" in the chroot to get it into log.
+
+But I'm close to 100% sure it is version 4.2 as the VM is set up from scratch for every build and the chroot is also set up from scratch.
+
+Here we go:
+https://travis-ci.com/github/VDR4Arch/vdr4arch/jobs/309187889#L332
+
+Created with this commit:
+https://github.com/VDR4Arch/vdr4arch/commit/29ec2197483bf15102c889eef2749bb0cffc0839
+
+This is a "Ubuntu Bionic" thing.
+
+I've tried again on a VM with up-to-date Ubuntu Bionic and get the same segfault.
+
+For comparison I've placed the Debian build of qemu-user-static version 4.2 to my Arch Linux VM and have no crash there.
+
+So either the kernel version or some kernel configuration. Now I'm trying to get a coredump on my VM.
+
+Managed to get a coredump. Coredumps usually tell me nothing but maybe someone here can find something useful in there...
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting older bugs to "Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+