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
