On 17.11.2017 16:47, Daniel P. Berrange wrote: > 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 Ahh, this is fixed upstream already by eae746b2d the way you suggest )) -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
