Re: [libvirt PATCH v2 0/5] Add support for vDPA block devices
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 <pkrempa(a)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