cynthia / gperftools

Automatically exported from code.google.com/p/gperftools
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

Option to disable writing tcmalloc larg allocation messages to stderr #357

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
tcmalloc will print messages such as the following to stderr:

tcmalloc: large alloc 1176436736 bytes == 0x3177a000 @  0x7f909f9fce6c 0x401ef9 
0x40b931 0x44f1da 0x44be5f 0x4502c3 0x7f909ed9bc4d 0x401db9

Looking at the code, the output to stderr looks built in.  Is there a mechanism 
for turning this off, as not to contaminate stderr unless there is actually an 
error?

Original issue reported on code.google.com by nilsho...@gmail.com on 29 Jul 2011 at 7:43

GoogleCodeExporter commented 9 years ago
Yes, you can set the envvar TCMALLOC_LARGE_ALLOC_REPORT_THRESHOLD to some huge 
value to disable this.

Original comment by csilv...@gmail.com on 29 Jul 2011 at 9:19

GoogleCodeExporter commented 9 years ago
That works well but if we are distributing a binary then it should be modifying 
the environment?

Original comment by nilsho...@gmail.com on 29 Jul 2011 at 10:51

GoogleCodeExporter commented 9 years ago
You can call setenv() from within your binary -- at main() or whatever.  If you 
wanted to be super-polite, you could check that the envvar isn't already set, 
and only set it if so.  (I agree there are cleaner ways to do this than via 
envvars, but I don't think there's any rule that you shouldn't modify the 
environment.  Any mods you make will only affect your binary anyway.)

Original comment by csilv...@gmail.com on 29 Jul 2011 at 10:58

GoogleCodeExporter commented 9 years ago
Please reconsider.

It's not possible influence this by "call setenv() from within your binary -- 
at main()" since at that point the static initializer that reads 
TCMALLOC_LARGE_ALLOC_REPORT_THRESHOLD has already run.

Original comment by hakan.hj...@gmail.com on 13 Aug 2012 at 5:12