[libvirt] encountered failed test cases with latest checkout of libvirt

[Eric Blake]

On 03/29/2017 04:47 AM, Michal Privoznik wrote:

>>
>> For the valgrind testing with 'make -C tests valgrind', the errors were
>> *mostly* due to
>> "FATAL: can't open suppressions file "./.valgrind.supp". I am using
>> valgrind 3.12.0.

I suspect it may be a simple tweak to makefile to supply an absolute
reference instead of relative to .valgrind.supp so that 'make -C' would
find the right file, for this situation.

> 
> 
> That's weird, the file should be there. What is a problem though is our
> mocking. Due to some weird glibc-ness, valgrind cannot handle libraries
> that have some unresolved symbols. For instance, if library L that is
> loaded from binary B provides symbols L1 and L2 but rely on symbol B1,
> valgrind (in fact glibc) fails to load the binary even though if run
> without valgrind everything works just fine.
> 
> I've looked into this the other day and went from our sources to
> valgrind ones and from there to glibc where I got lost. For instance,
> virpcitest fails because virpcimock uses virAlloc, virFree and other
> internal APIs even though it's not linking with libvirt_util.
> 
> Frankly, I've no idea how to fix this. Perhaps Eric have a bright idea?

Sorry, no bright ideas here.  A strict link ordering (so that no library
relies on unresolved symbols) is a good idea for mingw, so it's worth
shooting for anyways, and may clean up the valgrind issues, but I'm not
sure how easy or hard it would be to rearrange link orders to get to
that point.

> BTW: linking the mock with libvirt_util fails in exactly the opposite
> case - when not running under valgrind.
> 
> Michal
> 

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 604 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170329/882fb3a9/attachment-0001.sig>