crash at qemu_iohandler_poll (iohandler.c:124) on macos 10.8.2
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
QEMU |
Expired
|
Undecided
|
Unassigned |
Bug Description
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-
With images, kernel, and initrd described here:
http://
And I get:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION
0x000000010142f2d0 in ?? ()
(gdb) bt
#0 0x000000010142f2d0 in ?? ()
#1 0x000000010016e209 in qemu_iohandler_poll (readfds=
#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=0x7fff5fbf
#5 0x00000001001d6013 in main (argc=12, argv=0x7fff5fbf
(gdb) frame 1
#1 0x000000010016e209 in qemu_iohandler_poll (readfds=
124 ioh->fd_
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. _FAILURE at address: 0x000000010142f2d0 0x10097ca00, writefds= 0x10097ca80, xfds=0x10097cb00, ret=4) at iohandler.c:124 f360, envp=0x7fff5fbf f3c8) at vl.c:3992 f360) at ui/cocoa.m:884 0x10097ca00, writefds= 0x10097ca80, xfds=0x10097cb00, ret=4) at iohandler.c:124 read(ioh- >opaque) ;
> Reason: KERN_PROTECTION
> 0x000000010142f2d0 in ?? ()
>
> (gdb) bt
> #0 0x000000010142f2d0 in ?? ()
> #1 0x000000010016e209 in qemu_iohandler_poll (readfds=
> #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=0x7fff5fbf
> #5 0x00000001001d6013 in main (argc=12, argv=0x7fff5fbf
> (gdb) frame 1
> #1 0x000000010016e209 in qemu_iohandler_poll (readfds=
> 124 ioh->fd_
> 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