On Tue, Sep 12, 2023 at 16:11:01 -0500, Jonathon Jongsma wrote: > On 9/12/23 7:00 AM, Peter Krempa wrote: > > On Mon, Sep 11, 2023 at 16:53:42 -0500, Jonathon Jongsma wrote: > > > see https://bugzilla.redhat.com/show_bug.cgi?id=1900770. > > > > > > Changes in v2: > > > - Don't use virStorageSource->path for vdpa device path to avoid > > > clashing with > > > existing path functionality > > > - Move vdpa device opening to the qemuProcessPrepareHostStorageSource() > > > function rather than the qemuDomainPrepareStorageSource() function. > > > This > > > also required some additional support in the tests for setting up the > > > objects properly for testing. > > > - rebased to latest master branch > > > > Reviewed-by: Peter Krempa <pkre...@redhat.com> > > > > I pushed this series, but for some reason only the ubuntu images are failing > CI with no useful output: > https://gitlab.com/libvirt/libvirt/-/pipelines/1001459836 > > I suspect it may be related to address sanitizer stuff, does anybody have > tips on getting more information about this failure?
Usually valgrind does a good job of finding everyhting the sanitizer complains about: $ valgrind --trace-children=yes --leak-check=full ./tests/qemuxml2argvtest [...] ==352693== 18 bytes in 1 blocks are definitely lost in loss record 257 of 684 ==352693== at 0x484182F: malloc (vg_replace_malloc.c:431) ==352693== by 0x51DA07F: xmlStrndup (in /usr/lib64/libxml2.so.2.10.4) ==352693== by 0x49D918E: virXMLPropStringRequired (virxml.c:321) ==352693== by 0x4A0D866: virDomainStorageSourceParse (domain_conf.c:7526) ==352693== by 0x4A0E9F0: virDomainDiskDefParseSourceXML (domain_conf.c:7926) ==352693== by 0x4A0ECCF: virDomainDiskDefParseXML (domain_conf.c:8000) ==352693== by 0x4A2DA93: virDomainDefParseXML (domain_conf.c:18767) ==352693== by 0x4A31678: virDomainDefParseNode (domain_conf.c:19557) ==352693== by 0x134000: testCompareXMLToArgv (qemuxml2argvtest.c:566) ==352693== by 0x1356B9: virTestRun (testutils.c:143) ==352693== by 0x135940: virTestRunLog (testutils.c:198) ==352693== by 0x11D422: mymain (qemuxml2argvtest.c:1164) Looks like the new field is not freed. I'll post the patch soon
