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
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
|
permissions: 0.988
debug: 0.982
register: 0.975
architecture: 0.953
user-level: 0.949
device: 0.947
peripherals: 0.941
ppc: 0.937
PID: 0.932
arm: 0.922
files: 0.920
socket: 0.917
TCG: 0.914
performance: 0.914
risc-v: 0.914
semantic: 0.905
network: 0.904
graphic: 0.902
assembly: 0.901
boot: 0.884
kernel: 0.878
KVM: 0.870
virtual: 0.869
VMM: 0.859
vnc: 0.839
mistranslation: 0.838
hypervisor: 0.828
x86: 0.575
i386: 0.382
crash at qemu_iohandler_poll (iohandler.c:124) on macos 10.8.2
I'm seeing consistent hangs / crashes on MacOS 10.8.2 with 1.3.0. I've tried both gcc-4.2 and clang. I've tried a half a dozen different images/kernels.
I configured qemu like this:
./configure --disable-sdl --disable-kvm --enable-cocoa --cc=gcc-4.2 --host-cc=gcc-4.2 --enable-debug --extra-cflags=-g --extra-ldflags=-g
And ran it like this:
qemu-system-arm -nographic -M versatilepb -kernel vmlinuz-2.6.32-5-versatile -initrd initrd.img-2.6.32-5-versatile -hda debian_squeeze_armel_standard.qcow2 -append "root=/dev/sda1 console=ttyAMA0"
With images, kernel, and initrd described here:
http://psellos.com/2012/08/2012.08.qemu-arm-osx.html
And I get:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x000000010142f2d0
0x000000010142f2d0 in ?? ()
(gdb) bt
#0 0x000000010142f2d0 in ?? ()
#1 0x000000010016e209 in qemu_iohandler_poll (readfds=0x10097ca00, writefds=0x10097ca80, xfds=0x10097cb00, ret=4) at iohandler.c:124
#2 0x0000000100172acf in main_loop_wait (nonblocking=0) at main-loop.c:418
#3 0x0000000100207bbf in main_loop () at vl.c:1765
#4 0x000000010020e7b0 in qemu_main (argc=12, argv=0x7fff5fbff360, envp=0x7fff5fbff3c8) at vl.c:3992
#5 0x00000001001d6013 in main (argc=12, argv=0x7fff5fbff360) at ui/cocoa.m:884
(gdb) frame 1
#1 0x000000010016e209 in qemu_iohandler_poll (readfds=0x10097ca00, writefds=0x10097ca80, xfds=0x10097cb00, ret=4) at iohandler.c:124
124 ioh->fd_read(ioh->opaque);
Current language: auto; currently c
(gdb) p ioh
$1 = (IOHandlerRecord *) 0x10142f110
(gdb) p *ioh
$2 = {
fd_read_poll = 0,
fd_read = 0x10017212b <sigfd_handler>,
fd_write = 0,
opaque = 0x3,
next = {
le_next = 0x0,
le_prev = 0x105d00bc0
},
fd = 3,
deleted = false
}
On Mon, Dec 31, 2012 at 08:46:45PM -0000, Christopher Mason wrote:
> Public bug reported:
>
> I'm seeing consistent hangs / crashes on MacOS 10.8.2 with 1.3.0. I've
> tried both gcc-4.2 and clang. I've tried a half a dozen different
> images/kernels.
Which QEMU version are you building? Have you tried qemu.git/master?
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x000000010142f2d0
> 0x000000010142f2d0 in ?? ()
>
> (gdb) bt
> #0 0x000000010142f2d0 in ?? ()
> #1 0x000000010016e209 in qemu_iohandler_poll (readfds=0x10097ca00, writefds=0x10097ca80, xfds=0x10097cb00, ret=4) at iohandler.c:124
> #2 0x0000000100172acf in main_loop_wait (nonblocking=0) at main-loop.c:418
> #3 0x0000000100207bbf in main_loop () at vl.c:1765
> #4 0x000000010020e7b0 in qemu_main (argc=12, argv=0x7fff5fbff360, envp=0x7fff5fbff3c8) at vl.c:3992
> #5 0x00000001001d6013 in main (argc=12, argv=0x7fff5fbff360) at ui/cocoa.m:884
> (gdb) frame 1
> #1 0x000000010016e209 in qemu_iohandler_poll (readfds=0x10097ca00, writefds=0x10097ca80, xfds=0x10097cb00, ret=4) at iohandler.c:124
> 124 ioh->fd_read(ioh->opaque);
> Current language: auto; currently c
> (gdb) p ioh
> $1 = (IOHandlerRecord *) 0x10142f110
> (gdb) p *ioh
> $2 = {
> fd_read_poll = 0,
> fd_read = 0x10017212b <sigfd_handler>,
The fd_read() function pointer should be called here. But somehow we
end up with 0x000000010142f2d0, which is awefully close to the
IOHandlerRecord (0x10142f110).
Perhaps printing out the entire io_handlers list would be interesting
too.
Does this happen at an unspecified point or is it always when the
fd_read sigfd_handler() callback is invoked? (You could put a
breakpoint on sigfd_handler() and continue the first time it is hit to
check this.)
Stefan
Using qemu master rev dbd99ae..25bbf61 configured with:
./configure --disable-sdl --disable-kvm --enable-cocoa --enable-debug --extra-cflags=-g --extra-ldflags=-g
(I'm using clang 4.1 now. Should I be using clang or gcc 4.2? Are these the right config args?)
(gdb) b sigfd_handler
Breakpoint 1 at 0x1001c098d: file main-loop.c, line 41.
(gdb) r -nographic -M versatilepb -kernel vmlinuz-2.6.32-5-versatile -initrd initrd.img-2.6.32-5-versatile -hda debian_squeeze_armel_standard.qcow2 -append "root=/dev/sda1 console=ttyAMA0"
...
Breakpoint 1, sigfd_handler (opaque=0x3) at main-loop.c:41
41 int fd = (intptr_t)opaque;
(gdb) bt
#0 sigfd_handler (opaque=0x3) at main-loop.c:41
#1 0x00000001001baaee in qemu_iohandler_poll (readfds=0x100a0938c, writefds=0x100a0940c, xfds=0x100a0948c, ret=3) at iohandler.c:124
#2 0x00000001001c00bb in main_loop_wait (nonblocking=0) at main-loop.c:418
#3 0x000000010027bde4 in main_loop () at vl.c:1765
#4 0x00000001002765c2 in qemu_main (argc=12, argv=0x7fff5fbff340, envp=0x7fff5fbff3a8) at vl.c:4014
#5 0x0000000100239a13 in main (argc=12, argv=0x7fff5fbff340) at ui/cocoa.m:884
Current language: auto; currently minimal
(gdb) p io_handlers
$1 = {
lh_first = 0x102102ab0
}
(gdb) p * io_handlers.lh_first
$2 = {
fd_read_poll = 0x1001fad60 <stdio_read_poll>,
fd_read = 0x1001fae20 <stdio_read>,
fd_write = 0,
opaque = 0x1021029c0,
next = {
le_next = 0x102100000,
le_prev = 0x100a09368
},
fd = 0,
deleted = false
}
(gdb) p * io_handlers.lh_first->next.le_prev
$3 = (struct IOHandlerRecord *) 0x102102ab0
(gdb) p * io_handlers.lh_first->next.le_next
$4 = {
fd_read_poll = 0,
fd_read = 0x1001c0970 <sigfd_handler>,
fd_write = 0,
opaque = 0x3,
next = {
le_next = 0x0,
le_prev = 0x102102ad0
},
fd = 3,
deleted = false
}
(gdb) c
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0000000102100040
0x0000000102100040 in ?? ()
(gdb) bt
#0 0x0000000102100040 in ?? ()
#1 0x00000001001baaee in qemu_iohandler_poll (readfds=0x100a0938c, writefds=0x100a0940c, xfds=0x100a0948c, ret=3) at iohandler.c:124
#2 0x00000001001c00bb in main_loop_wait (nonblocking=0) at main-loop.c:418
#3 0x000000010027bde4 in main_loop () at vl.c:1765
#4 0x00000001002765c2 in qemu_main (argc=12, argv=0x7fff5fbff340, envp=0x7fff5fbff3a8) at vl.c:4014
#5 0x0000000100239a13 in main (argc=12, argv=0x7fff5fbff340) at ui/cocoa.m:884
(gdb) p io_handlers
$5 = {
lh_first = 0x102102ab0
}
(gdb) p * io_handlers.lh_first
$6 = {
fd_read_poll = 0x1001fad60 <stdio_read_poll>,
fd_read = 0x1001fae20 <stdio_read>,
fd_write = 0,
opaque = 0x1021029c0,
next = {
le_next = 0x102100000,
le_prev = 0x100a09368
},
fd = 0,
deleted = false
}
(gdb) p * io_handlers.lh_first->next.le_next
$8 = {
fd_read_poll = 0,
fd_read = 0x1001c0970 <sigfd_handler>,
fd_write = 0,
opaque = 0x3,
next = {
le_next = 0x0,
le_prev = 0x102102ad0
},
fd = 3,
deleted = false
}
(gdb) p * io_handlers.lh_first->next.le_prev
$9 = (struct IOHandlerRecord *) 0x102102ab0
On Fri, Jan 04, 2013 at 06:09:30PM -0000, Christopher Mason wrote:
> Using qemu master rev dbd99ae..25bbf61 configured with:
>
> ./configure --disable-sdl --disable-kvm --enable-cocoa --enable-debug
> --extra-cflags=-g --extra-ldflags=-g
>
> (I'm using clang 4.1 now. Should I be using clang or gcc 4.2? Are these
> the right config args?)
I have never used QEMU on Mac myself, sorry. Maybe someone else can
help.
> (gdb) b sigfd_handler
> Breakpoint 1 at 0x1001c098d: file main-loop.c, line 41.
>
> (gdb) r -nographic -M versatilepb -kernel vmlinuz-2.6.32-5-versatile -initrd initrd.img-2.6.32-5-versatile -hda debian_squeeze_armel_standard.qcow2 -append "root=/dev/sda1 console=ttyAMA0"
> ...
> Breakpoint 1, sigfd_handler (opaque=0x3) at main-loop.c:41
> 41 int fd = (intptr_t)opaque;
> (gdb) bt
> #0 sigfd_handler (opaque=0x3) at main-loop.c:41
> #1 0x00000001001baaee in qemu_iohandler_poll (readfds=0x100a0938c, writefds=0x100a0940c, xfds=0x100a0948c, ret=3) at iohandler.c:124
> #2 0x00000001001c00bb in main_loop_wait (nonblocking=0) at main-loop.c:418
> #3 0x000000010027bde4 in main_loop () at vl.c:1765
> #4 0x00000001002765c2 in qemu_main (argc=12, argv=0x7fff5fbff340, envp=0x7fff5fbff3a8) at vl.c:4014
> #5 0x0000000100239a13 in main (argc=12, argv=0x7fff5fbff340) at ui/cocoa.m:884
> Current language: auto; currently minimal
> (gdb) p io_handlers
> $1 = {
> lh_first = 0x102102ab0
> }
> (gdb) p * io_handlers.lh_first
> $2 = {
> fd_read_poll = 0x1001fad60 <stdio_read_poll>,
> fd_read = 0x1001fae20 <stdio_read>,
> fd_write = 0,
> opaque = 0x1021029c0,
> next = {
> le_next = 0x102100000,
> le_prev = 0x100a09368
> },
> fd = 0,
> deleted = false
> }
> (gdb) p * io_handlers.lh_first->next.le_prev
> $3 = (struct IOHandlerRecord *) 0x102102ab0
> (gdb) p * io_handlers.lh_first->next.le_next
> $4 = {
> fd_read_poll = 0,
> fd_read = 0x1001c0970 <sigfd_handler>,
> fd_write = 0,
> opaque = 0x3,
> next = {
> le_next = 0x0,
> le_prev = 0x102102ad0
> },
> fd = 3,
> deleted = false
> }
>
> (gdb) c
>
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x0000000102100040
> 0x0000000102100040 in ?? ()
> (gdb) bt
> #0 0x0000000102100040 in ?? ()
> #1 0x00000001001baaee in qemu_iohandler_poll (readfds=0x100a0938c, writefds=0x100a0940c, xfds=0x100a0948c, ret=3) at iohandler.c:124
> #2 0x00000001001c00bb in main_loop_wait (nonblocking=0) at main-loop.c:418
> #3 0x000000010027bde4 in main_loop () at vl.c:1765
> #4 0x00000001002765c2 in qemu_main (argc=12, argv=0x7fff5fbff340, envp=0x7fff5fbff3a8) at vl.c:4014
> #5 0x0000000100239a13 in main (argc=12, argv=0x7fff5fbff340) at ui/cocoa.m:884
>
> (gdb) p io_handlers
> $5 = {
> lh_first = 0x102102ab0
> }
> (gdb) p * io_handlers.lh_first
> $6 = {
> fd_read_poll = 0x1001fad60 <stdio_read_poll>,
> fd_read = 0x1001fae20 <stdio_read>,
> fd_write = 0,
> opaque = 0x1021029c0,
> next = {
> le_next = 0x102100000,
> le_prev = 0x100a09368
> },
> fd = 0,
> deleted = false
> }
> (gdb) p * io_handlers.lh_first->next.le_next
> $8 = {
> fd_read_poll = 0,
> fd_read = 0x1001c0970 <sigfd_handler>,
> fd_write = 0,
> opaque = 0x3,
> next = {
> le_next = 0x0,
> le_prev = 0x102102ad0
> },
> fd = 3,
> deleted = false
> }
> (gdb) p * io_handlers.lh_first->next.le_prev
> $9 = (struct IOHandlerRecord *) 0x102102ab0
This is interesting. The iohandlers are intact - there was no
memory corruption there. The fact that it crashes after executing
sigfd_handler() once is suspicious.
My next suggestion is to break on iohandler.c:124 and find out why
0x0000000102100040 is getting called. Really it should be
sigfd_handler() that gets called again. This may require a few tries
and probably familiarity with assembly to debug.
I have pinged other QEMU contributors who have Macs. Perhaps they can
help better from here.
Stefan
Just a note that IME trying to debug QEMU under gdb on MacOS doesn't work very well. In particular as far as I can tell gdb breaks sigwait() such that the sigwait() in sigwait_compat() can return 0 without setting the int* sig. This causes QEMU to write an uninitialized value into the qemu_signalfd_siginfo struct it sends down the pipe, and then sigfd_handler() calls sigaction() with this bogus data as the signal number. Since sigfd_handler() doesn't check the return value from sigaction() we then proceed to leap off into nowhere.
sigfd_handler() should probably be checking the return value from sigaction() but the underlying problem is MacOS and/or its gdb breaking sigwait() behaviour somehow.
Can you still reproduce this problem wit the latest release of QEMU (currently version 2.9.0) and macOS, or could we close this bug nowadays?
[Expired for QEMU because there has been no activity for 60 days.]
|