On Fri, Nov 17, 2017 at 04:45:27PM +0300, Nikolay Shirokovskiy wrote: > > > On 17.11.2017 16:40, Daniel P. Berrange wrote: > > On Fri, Nov 17, 2017 at 04:31:13PM +0300, Nikolay Shirokovskiy wrote: > >> > >> > >> On 17.11.2017 16:24, Daniel P. Berrange wrote: > >>> On Fri, Nov 17, 2017 at 04:17:37PM +0300, Nikolay Shirokovskiy wrote: > >>>> If one of the libraries is compiled with tcmalloc then > >>>> the latter will add GLIBCPP_FORCE_NEW and GLIBCXX_FORCE_NEW to > >>>> environment at startup and thus break commandtest. > >>> > >>> How are they getting those envs into our environment after we clean it > >>> out ? We strongly aim to prevent any non-whitelisted env variable > >>> leakage into children we spawn, so I would really like to kill these > >>> env vars instead of changin the test. > >> > >> They inserted at process startup I guess [1]. They are cleared out by commandtest > >> but visible in commandhelper. > > > > Hmm, so is comandhelper getting linked to tcmalloc by mistake then ? > > If so, how easy is it to stop it being linked > > It is not liked directly. In my case the chain is > libdevmapper.so -> libudev.so -> libtcmalloc.so. It is distro specific > but I guess other can step across this issue and for a different chain. One > just need to link on of the libraries libvirt uses to tcmalloc. Ah I see. I think this smells like a bug in the tests/Makefile.am The commandhelper binary should not link to anything at all except for libc (and perhaps gnulib, but possibly even that is redundant) Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
