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. >