Re: [Qemu-devel] [PATCH v4 00/10] curl: fix curl read

[Paolo Bonzini <pbonzini@redhat.com>]

Il 22/05/2013 11:44, Richard W.M. Jones ha scritto:
> On Wed, May 22, 2013 at 11:16:40AM +0800, Fam Zheng wrote:
>> Changes from v3:
>>   01, 06, 07: Add QLIST_INIT in qemu_open to initialize each list.
>>   07: Move clean up for s->acbs from later patch to here. Use qemu_aio_relase instead of g_free on acb.
>>       Fix use-after-free bug. [Rich]
> 
> This version definitely works better.  I'm able to open the guest and
> perform some simple guestfish commands.
> 
>   - - -
> 
> However I'm still able to hit a crash in qemu, *but* it appears this
> crash has nothing to do with your code.  The same crash happens
> whether or not I apply your patch, and occurs in common block code.
> 
> Here are the details of that other crash (qemu from git w/o your patch,
> curl from git):
> 
> $ LD_LIBRARY_PATH=~/d/curl/lib/.libs LIBGUESTFS_QEMU=~/d/qemu/qemu.wrapper LIBGUESTFS_BACKEND=direct ./run ./fish/guestfish -a http://192.168.0.249/scratch/winxp.img -i
> 
> Welcome to guestfish, the guest filesystem shell for
> editing virtual machine filesystems and disk images.
> 
> Type: 'help' for help on commands
>       'man' to read the manual
>       'quit' to quit the shell
> 
> Operating system: Microsoft Windows XP
> /dev/sda1 mounted on /
> 
>> <fs> find /
> libguestfs: error: appliance closed the connection unexpectedly.
> This usually means the libguestfs appliance crashed.
> See http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs
> for information about how to debug libguestfs and report bugs.
> libguestfs: error: /home/rjones/d/qemu/qemu.wrapper killed by signal 11 (Segmentation fault).
> To see full error messages you may need to enable debugging.
> See http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs
> libguestfs: error: receive_file_data: parse error in reply callback
> libguestfs: error: /home/rjones/d/libguestfs/tmp/libguestfsN7yyt4/find1: error in chunked encoding
> 
> [...]
> 
> Program terminated with signal 11, Segmentation fault.
> Thread 1 (Thread 0x7f65acf0ea00 (LWP 21370)):
> #0  0x0000000000000000 in ?? ()
> #1  0x00007f65ad005b3e in bdrv_co_io_em (is_write=true, iov=0x7f65b0b55228, 
>     nb_sectors=8, sector_num=2104919, bs=0x7f65ae0d26f0) at block.c:4283

Something is trying to write, but there's no write operation defined for
CURL.

I guess curl (and other backends too) should reject being opened for
write.  Alternatively, block.c could do that for them.

Paolo

> #2  bdrv_co_writev_em (bs=0x7f65ae0d26f0, sector_num=2104919, nb_sectors=8, 
>     iov=0x7f65b0b55228) at block.c:4310
> #3  0x00007f65ad00c125 in bdrv_co_do_writev (bs=0x7f65ae0d26f0, sector_num=
>     2104919, nb_sectors=8, qiov=0x7f65b0b55228, flags=(unknown: 0))
>     at block.c:2625
> #4  0x00007f65ad00c125 in bdrv_co_do_writev (bs=0x7f65ae0cfcd0, sector_num=
>     2104919, nb_sectors=8, qiov=0x7f65b0b55228, flags=flags@entry=(unknown: 0))
>     at block.c:2625
> #5  0x00007f65ad00c288 in bdrv_co_do_rw (opaque=0x7f65afbed140) at block.c:4139
> #6  0x00007f65ad0436ea in coroutine_trampoline (i0=<optimized out>, 
>     i1=<optimized out>) at coroutine-ucontext.c:118
> #7  0x00007f65a5ae96c0 in ?? () from /lib64/libc.so.6
> #8  0x00007fff88fd1ab0 in ?? ()
> #9  0xe0e0e0e0e0e0e0e0 in ?? ()
> #10 0x0000000000000000 in ?? ()
> 
> Rich.
>