summary refs log tree commit diff stats
path: root/results/classifier/108/other/1311614
diff options
context:
space:
mode:
Diffstat (limited to 'results/classifier/108/other/1311614')
-rw-r--r--results/classifier/108/other/1311614137
1 files changed, 137 insertions, 0 deletions
diff --git a/results/classifier/108/other/1311614 b/results/classifier/108/other/1311614
new file mode 100644
index 000000000..0eb5298e3
--- /dev/null
+++ b/results/classifier/108/other/1311614
@@ -0,0 +1,137 @@
+device: 0.901
+permissions: 0.839
+vnc: 0.832
+other: 0.827
+debug: 0.826
+network: 0.805
+PID: 0.801
+semantic: 0.797
+graphic: 0.789
+performance: 0.782
+socket: 0.770
+files: 0.766
+KVM: 0.743
+boot: 0.682
+
+qemu-arm segfaults with gcc 4.9.0
+
+I have an ARM chroot that working with qemu-arm emulation
+
+[root@filzbach fedya]# cat /proc/sys/fs/binfmt_misc/arm
+enabled
+interpreter /usr/bin/qemu-arm-binfmt
+flags: P
+offset 0
+magic 7f454c4601010100000000000000000002002800
+mask ffffffffffffff00fffffffffffffffffeffffff
+
+
+In chroot installed gcc dependencies with 4.9.0 version
+
+sudo rpm --root /home/fedya/root/ -qa | grep 4.9.0
+
+libgcc1-4.9.0_2014.04-1-omv2013.0.armv7hl
+libgomp1-4.9.0_2014.04-1-omv2013.0.armv7hl
+libstdc++6-4.9.0_2014.04-1-omv2013.0.armv7hl
+gcc-4.9.0_2014.04-1-omv2013.0.armv7hl
+gcc-cpp-4.9.0_2014.04-1-omv2013.0.armv7hl
+libstdc++-devel-4.9.0_2014.04-1-omv2013.0.armv7hl
+gcc-c++-4.9.0_2014.04-1-omv2013.0.armv7hl
+
+
+When i try to run "rpm" , "rpmbuild", "rpm2cpio"command i always see qemu segfault message
+
+
+example:
+
+[root@filzbach /]# uname -a
+Linux filzbach.lindev.ch 3.13.6-nrjQL-desktop-70omv #1 SMP PREEMPT Wed Mar 12 21:40:00 UTC 2014 armv7l armv7l armv7l GNU/Linux
+
+[root@filzbach /]# rpm
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+
+
+Segfault became apparent only after gcc upgrade from 4.8.3 to 4.9.0.
+
+When i downgrade it to 4.8.3 all working fine again.
+It looks like a qemu bug with gcc.
+
+
+P.S.
+I tried to rebuild qemu with gcc 4.9.0
+I tried to build qemu from git sources, from fedora sources, from suse sources etc.
+
+And of course i rebuilt rpm package with latest gcc 4.9.0
+Btw all working fine on a real hardware.
+
+Bump
+
+A backtrace of where the crash is in QEMU might be interesting.
+
+Do you have any howto to  produce backtrace?
+
+I debugged it originally but did only suggest a temporary workaround...
+The crash, not really in qemu, looks like this:
+
+--%<--
+Remote debugging using localhost:1235
+Reading symbols from
+/home/fedya/openmandriva/home/fedya/root/lib/ld-linux-armhf.so.3...Reading
+symbols from
+/home2/fedya/openmandriva/home/fedya/root/usr/lib/debug/lib/ld-2.19.so.debug...done.
+done.
+Loaded symbols for /home/fedya/openmandriva/home/fedya/root/lib/ld-linux-armhf.so.3
+0xf67dfd00 in _start ()
+   from /home/fedya/openmandriva/home/fedya/root/lib/ld-linux-armhf.so.3
+(gdb) c
+Continuing.
+
+Program received signal SIGSEGV, Segmentation fault.
+memset () at ../ports/sysdeps/arm/memset.S:53
+53              sfi_breg r3, \
+(gdb) bt
+#0  memset () at ../ports/sysdeps/arm/memset.S:53
+#1  0xf650b5da in __pthread_getaffinity_new (th=th@entry=4123619328, cpusetsize=4,
+    cpuset=0xf008) at ../nptl/sysdeps/unix/sysv/linux/pthread_getaffinity.c:41
+#2  0xf60ca6d8 in gomp_init_num_threads () at
+../../../libgomp/config/linux/proc.c:93
+#3  0xf60c28b2 in initialize_env () at ../../../libgomp/env.c:1187
+#4  0xf67ea514 in call_init (env=<optimized out>, argv=<optimized out>,
+    argc=<optimized out>, l=<optimized out>) at dl-init.c:76
+#5  _dl_init (main_map=0xf67fe908, argc=1, argv=0xf6ffecf4, env=0xf6ffecfc)
+    at dl-init.c:124
+#6  0xf67dfd32 in _dl_start_user ()
+   from /home/fedya/openmandriva/home/fedya/root/lib/ld-linux-armhf.so.3
+Backtrace stopped: previous frame identical to this frame (corrupt stack?)
+(gdb) q
+A debugging session is active.
+
+        Inferior 1 [Remote target] will be killed.
+
+Quit anyway? (y or n) y
+--%<--
+
+My suggestion was to report problems upstream ofcourse, and
+a temporary quick fix would be to replace libgomp from the one
+from gcc 4.8x or replace the body of gomp_init_num_threads
+from gcc-4.9.0/libgomp/config/linux/proc.c with the one from
+gcc-4.8.2/libgomp/config/linux/proc.c
+
+I believe gcc 4.9 is too smart, and some stub is missing somewhere,
+e.g. in the arm chroot checking /proc/cpuinfo shows x86_64 cpus.
+
+
+Hmm, getaffinity? Can you try applying this qemu patch:
+https://patches.linaro.org/30259/
+
+and see if it resolves the problem?
+
+
+Will do!
+Thanks
+
+Fixed, thanks
+
+Fixed by commit be3bd286bc06 back in 2014.
+
+