On Mon, Sep 19, 2022 at 09:41:57 +0200, Peter Krempa wrote: > On Mon, Sep 19, 2022 at 09:28:28 +0200, Peter Krempa wrote: > > On Mon, Sep 19, 2022 at 09:24:47 +0200, Peter Krempa wrote: > > > On Fri, Sep 16, 2022 at 13:30:07 +0100, Daniel P. Berrangé wrote: > > > > On Mon, Sep 05, 2022 at 03:57:03PM +0200, Kristina Hanicova wrote: > > > > [...] > > > > > A proper fix will be to not rely on stolen pointers though as doing this > > > is too fragile in other cases. > > [1] > > > > > Additional invalid read when valgrinding virtqemud: > > > > > > ==3172795== Invalid read of size 8 > > ==3172795== at 0x4A68B7F: virDomainObjResetAsyncJob (virdomainjob.c:185) > > ==3172795== by 0x4A68CF8: virDomainObjClearJob (virdomainjob.c:224) > > Okay this is the same problem as before. > > In 'qemuProcessQMPConnectMonitor' a temporary instance of 'xmlopt' to > allow creating a temporary domain object used to probe the capabilities > of qemu. The lifetime of 'xmlopt' is limited to > 'qemuProcessQMPConnectMonitor' but the domain object it helped to create > outlives the function and is disposed later. > > As noted in [1] relying on xmlopt outliving the domai object is too > fragile, and proper care must be taken to either copy the data if > appropriate or to ensure that the lifetime is indeed longer > (refcounting). Naive attempt that resolves all the invalid reads reported in this sub-thread: https://listman.redhat.com/archives/libvir-list/2022-September/234315.html
