Re: [Qemu-devel] [PATCH] Disable AIO for Mac OS X

[Anthony Liguori <anthony@codemonkey.ws>]

Alexander Graf wrote:
> The kill() is called, but we're never receiving the signal. Also when 
> I kill -31 manually from the outside, the signal handler isn't invoked.

Anyone know much about signal delivery in Darwin?  Is there a way to do 
thread signaling directly?

>> If for some crazy reason the OS X port spawns another thread 
>> somewhere without masking SIGUSR2 correctly, it could be that the 
>> signal is getting lost.
>
> Hm - according to gdb things look pretty normal, no?
>
> (gdb) thread apply all bt
>
> Thread 2 (process 804 thread 0x1003):
> #0  0x91b3c3ae in __semwait_signal ()
> #1  0x91b67326 in _pthread_cond_wait ()
> #2  0x91b8c9f0 in pthread_cond_timedwait$UNIX2003 ()
> #3  0x000157b5 in aio_thread (unused=0x0) at posix-aio-compat.c:52
> #4  0x91b66095 in _pthread_start ()
> #5  0x91b65f52 in thread_start ()
>
> Thread 1 (process 804 thread 0x10b):
> #0  0x91b846f2 in select$DARWIN_EXTSN ()
> #1  0x00081443 in qemu_aio_wait () at aio.c:173
> #2  0x00080ef5 in bdrv_read_em (bs=0x4, sector_num=0, buf=0x4 <Address 
> 0x4 out of bounds>, nb_sectors=4) at block.c:1447
> #3  0x0007f9c9 in bdrv_guess_geometry (bs=0x806a00, pcyls=0xbfffdfcc, 
> pheads=0xbfffdfc8, psecs=0xbfffdfc4) at block.c:773
> #4  0x0002a238 in ide_init2 (ide_state=<value temporarily unavailable, 
> due to optimizations>, hd0=0x806a00, hd1=0x0, irq=0x402a18) at 
> /Users/alex/work/qemu-osx/qemu/hw/ide.c:2844
> #5  0x0002af2d in pci_piix3_ide_init (bus=0x4, hd_table=0xbfffeaf0, 
> devfn=4, pic=0x402930) at /Users/alex/work/qemu-osx/qemu/hw/ide.c:3435
> #6  0x00044199 in pc_init1 (ram_size=<value temporarily unavailable, 
> due to optimizations>, vga_ram_size=8388608, boot_device=0x11d946 
> "cad", kernel_filename=0x0, kernel_cmdline=0x11d33c "", 
> initrd_filename=0x0, pci_enabled=1, cpu_model=0x0) at 
> /Users/alex/work/qemu-osx/qemu/hw/pc.c:1027
> #7  0x000066e1 in main (argc=5, argv=0xbffff360, envp=0xbffff378) at 
> /Users/alex/work/qemu-osx/qemu/vl.c:5520

Can you dump the sigmasks of each thread to see if they're blocking them 
correctly?  Perhaps thread 2 is receiving the SIGUSR2 for some weird reason?

Maybe try a different signal.  Maybe SIGUSR2 has some significance in 
Darwin.

Regards,

Anthony Liguori

> Alex
>
>>
>>
>> Regards,
>>
>> Anthony Liguori
>>
>>>> FWIW, at this point, we could drop the signal entirely and just use 
>>>> a pipe for communication.  Right now we use a signal that we catch 
>>>> and then write to a pipe from the signal handler.  We did this 
>>>> because that's how posix-aio worked but since we don't use 
>>>> posix-aio anymore, we're no longer limited by that.
>>>
>>> Hum - sounds like more effort and more probable breakage than 
>>> tracking this down ;-).
>>
>>> Alex
>>
>