Andreas Färber <afaer...@suse.de> writes:
> Am 28.09.2015 um 22:08 schrieb Markus Armbruster:
>> Several devices don't survive object_unref(object_new(T)): they crash
>> or hang during cleanup, or they leave dangling pointers behind.
>>
>> This breaks at least device-list-properties, because
>> qmp_device_list_properties() needs to create a device to find its
>> properties. Broken in commit f4eb32b "qmp: show QOM properties in
>> device-list-properties", v2.1. Example reproducer:
>>
>> $ qemu-system-aarch64 -nodefaults -display none -machine none -S
>> -qmp stdio
>> {"QMP": {"version": {"qemu": {"micro": 50, "minor": 4, "major":
>> 2}, "package": ""}, "capabilities": []}}
>> { "execute": "qmp_capabilities" }
>> {"return": {}}
>> { "execute": "device-list-properties", "arguments": {
>> "typename": "pxa2xx-pcmcia" } }
>> qemu-system-aarch64: /home/armbru/work/qemu/memory.c:1307:
>> memory_region_finalize: Assertion `((&mr->subregions)->tqh_first ==
>> ((void *)0))' failed.
>> Aborted (core dumped)
>> [Exit 134 (SIGABRT)]
>>
>> Unfortunately, I can't fix the problems in these devices right now.
>> Instead, add DeviceClass member cannot_even_create_with_object_new_yet
>> to mark them:
>
> This name is very misleading unfortunately. You must be able to create
> any QOM object with object_new(), you just can't clean them up IIUC.
Fair enough. Initially, I had crashes in object_new(), too, but they
eventually turned out to be innocent victims of prior memory corruption.
> What about cannot_clean_up_with_finalize_yet or irreversible_to_create?
I'll use the former or something very similar.
> ACK for the general approach of adding a new ugly field. ;)
Thanks!
