[...]
>>> Also, once you do what I'm suggesting, the crash from 6/9 will be resolved,
>>> however I still would like to see the @reply structure in
>>> qemuDomainGetBlockIoTune initialized properly on the stack.
>>
>> Weird how that crash happens for you, but not me especially since you
>> show 20 nparams which would seem to imply you're getting something back
>> from qemu. Even though it's not set by libvirt, qemu does default to
>> something (the id/alias for the object - in my case "drive-virtio-disk0"
>> for my qemu 2.6.2). What do you get from a command:
>>
>> virsh qemu-monitor-command $domain '{"execute":"query-block"}'
>>
>> ?
>>
>
> The returned JSON doesn't indicate any default on my qemu 2.6.0:
>
[...]
Ahhh... Right a domain without iotune adjustments... I think I checked
that at one time, but that was before I changed my mind in the
implementation from having "group" be some number to allowing a string
for group. With the number implementation I was just prepending some
constant string. So I guess I had it in my mind that I had already
tested that non iotune path.
> What I did was just to start a domain that had no block iotuning turned on
> whatsoever and when I saw the code I was like, wait, I need to try that as it
> looked suspicious at first glance (since at that moment I'd already known about
> the missing initialization) so I tried it and it crashed.
>
>> In any case, I'll add a memset(&reply, 0, sizeof(reply)) in the qemu
>
> Yeah, that would do, sure, but is there a problem with a plain static
> initialization at the function entry point? I mean that's where we (most of the
> time) put all of our initializations and also where everyone would actually
> expect such an assignment to take place...
>
> Erik
>
OK, I'll just change the definition:
virDomainBlockIoTuneInfo reply = {0};
John
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
