[libvirt] [PATCH 1/2] tests: commandtest: handle tcmalloc hacking environment

[Daniel P. Berrange]

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 :|