1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
|
mistranslation: 0.906
device: 0.901
instruction: 0.862
vnc: 0.832
other: 0.827
network: 0.805
semantic: 0.797
assembly: 0.796
graphic: 0.789
socket: 0.770
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.
|