
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.
[1] https://github.com/gperftools/gperftools/blob/6e3a702fb9c86eb450f22b326ecbce...
--- tests/commandhelper.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/tests/commandhelper.c b/tests/commandhelper.c index 1da2834..0f6ce07 100644 --- a/tests/commandhelper.c +++ b/tests/commandhelper.c @@ -94,8 +94,15 @@ int main(int argc, char **argv) { for (i = 0; i < n; i++) { /* Ignore the variables used to instruct the loader into * behaving differently, as they could throw the tests off. */ - if (!STRPREFIX(newenv[i], "LD_")) - fprintf(log, "ENV:%s\n", newenv[i]); + if (STRPREFIX(newenv[i], "LD_")) + continue; + + /* Fix tests if tcmalloc is used in libraries */ + if (STRPREFIX(newenv[i], "GLIBCPP_FORCE_NEW=") || + STRPREFIX(newenv[i], "GLIBCXX_FORCE_NEW=")) + continue; + + fprintf(log, "ENV:%s\n", newenv[i]); }
open_max = sysconf(_SC_OPEN_MAX); -- 1.8.3.1
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Regards, Daniel
Regards, Daniel