On Mon 10 Sep 2018 05:55:15 PM CEST, Eric Blake wrote: >> Hm, it actually doesn't crash for me even without the fix. Anyway, I >> don't have a good idea to make it more likely to crash and it's >> certainly better than nothing. > > Does running the test under valgrind reliably see the use-after-free?
Good question! :-) Unfortunately valgrind also needs a valid TMPDIR, so if you change it in order to reproduce the bug then valgrind won't run. I don't know if there's a way to tell valgrind to run the specified program with its own environment variables, but you can simply edit QEMU's get_tmp_filename() to always return an invalid directory, and then you get the expected result: Invalid read of size 8 at 0x859914: qobject_unref_impl (qobject.h:98) by 0x85F8EA: bdrv_open_inherit (block.c:2831) by 0x85F963: bdrv_open (block.c:2839) by 0x8BDD19: blk_new_open (block-backend.c:375) by 0x58A88A: blockdev_init (blockdev.c:599) by 0x58B6C4: drive_new (blockdev.c:990) by 0x59C004: drive_init_func (vl.c:1143) by 0x9A0CE3: qemu_opts_foreach (qemu-option.c:1106) by 0x5A4692: main (vl.c:4454) Address 0x1df67458 is 8 bytes inside a block of size 4,120 free'd at 0x4C2CDDB: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) by 0x97AD5F: qdict_destroy_obj (qdict.c:459) by 0x97CC04: qobject_destroy (qobject.c:41) by 0x85996F: qobject_unref_impl (qobject.h:100) by 0x85F6D4: bdrv_open_inherit (block.c:2794) by 0x85F963: bdrv_open (block.c:2839) [...] Berto