qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-block] [PATCH v8 00/11] Support streaming to an i


From: Alberto Garcia
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH v8 00/11] Support streaming to an intermediate layer
Date: Fri, 26 Jun 2015 10:01:52 +0200
User-agent: Notmuch/0.13.2 (http://notmuchmail.org) Emacs/23.2.1 (i486-pc-linux-gnu)

On Wed 24 Jun 2015 12:02:35 PM CEST, Alberto Garcia <address@hidden> wrote:

> What happens is that in stream_complete() all images that have been
> removed from the chain ([A], [B] and [C]) are closed, and then [D] is
> reopened in read-only mode.
>
> The reopen queue contains [C], that is still listed as a child of [D]
> although it's no longer a valid pointer.

Here's a simple way to access freed memory with the current master:

$ qemu-img create -f qcow2 base.qcow2 100M
$ qemu-img create -f qcow2 -o backing_file="base.qcow2" hd.qcow2
$ valgrind qemu-system-x86_64 -enable-kvm -monitor stdio -drive 
if=virtio,file=hd.qcow2

(qemu) block_stream virtio0 
(qemu) drive_del virtio0 
==15925== Thread 1:
==15925== Invalid read of size 8
==15925==    at 0x4C0C55: bdrv_close (block.c:1853)
==15925==    by 0x2E12C7: hmp_drive_del (blockdev.c:2173)
==15925==    by 0x1E72D5: handle_hmp_command (monitor.c:4058)
==15925==    by 0x1E9A44: monitor_command_cb (monitor.c:5081)
==15925==    by 0x578443: readline_handle_byte (readline.c:391)
==15925==    by 0x1E999E: monitor_read (monitor.c:5064)
==15925==    by 0x2E7064: qemu_chr_be_write (qemu-char.c:306)
==15925==    by 0x2E88AA: fd_chr_read (qemu-char.c:1012)
==15925==    by 0x9B6DB4C: g_main_context_dispatch (in 
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4400.1)
==15925==    by 0x4C6D7C: glib_pollfds_poll (main-loop.c:199)
==15925==    by 0x4C6E59: os_host_main_loop_wait (main-loop.c:244)
==15925==    by 0x4C6F18: main_loop_wait (main-loop.c:493)
==15925==  Address 0x1a86f2a0 is 16 bytes after a block of size 256 free'd
==15925==    at 0x4C29E90: free (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==15925==    by 0x6215767: pixman_image_unref (in 
/usr/lib/x86_64-linux-gnu/libpixman-1.so.0.32.6)
==15925==    by 0x490131: qemu_pixman_glyph_render (qemu-pixman.c:250)
==15925==    by 0x48AC70: vga_putcharxy (console.c:435)
==15925==    by 0x48B38C: console_refresh (console.c:567)
==15925==    by 0x48CC57: text_console_invalidate (console.c:1155)
==15925==    by 0x48A6A2: graphic_hw_invalidate (console.c:269)
==15925==    by 0x48E71D: text_console_update_cursor (console.c:1831)
==15925==    by 0x4C8245: timerlist_run_timers (qemu-timer.c:502)
==15925==    by 0x4C828D: qemu_clock_run_timers (qemu-timer.c:513)
==15925==    by 0x4C8596: qemu_clock_run_all_timers (qemu-timer.c:621)
==15925==    by 0x4C6F4E: main_loop_wait (main-loop.c:499)
==15925== 

As explained in my previous e-mail, the problem is that after the
block_stream operation, the bs->children list in hd.qcow2 still keeps a
pointer to base.qcow2 even when its memory has been freed.

Berto



reply via email to

[Prev in Thread] Current Thread [Next in Thread]