sampling_test.sh fail: wrong binary location detection

[GoogleCodeExporter]

Steps:  ./configure; make; make check

Problem:

The unittest 'sampling_test.sh' attempts to figure out the real binary
location of './sampling_test' by looking at the first line of output, which is:

tcmalloc: large alloc 65536 bytes == 0x785000 @  0x2aaaaaac46fb 0x2aaaaaae1918
0x3bd9551792 0x3bd9109a6c 0x3bd9551f21 0x3bd9596994 0x3bd959a471 0x3bd959ae50
0x2aaaaaad8bc0 0x2aaaaaae03c2

The _last_ line of the output is 'USAGE: .libs/sampling_test <base of
output files>', which is, I believe, what we're trying to capture.

So it uses 'large' instead of the correct binary.

I propose this patch (it fixes the problem for me):

--- sampling_test.sh    2009-03-25 17:02:07.043065000 -0700
+++ sampling_test2.sh   2009-03-25 17:02:46.859905000 -0700
@@ -52,7 +52,7 @@ OUTDIR="/tmp/sampling_test_dir"
 # libtool is annoying, and puts the actual executable in a different
 # directory, replacing the seeming-executable with a shell script.
 # We use the error output of sampling_test to indicate its real location
+SAMPLING_TEST_BINARY=`"$SAMPLING_TEST" 2>&1 | awk '/USAGE/ {print $2; exit;}'`
-SAMPLING_TEST_BINARY=`"$SAMPLING_TEST" 2>&1 | awk '{print $2; exit;}'`

 die() {
     echo "FAILED"

Version: linux x86-64, perftools 1.1

Note I do not have any special environment variables set, not sure why I'm
getting large alloc warnings.  Will look into it.

Original issue reported on code.google.com by mrab...@gmail.com on 29 Mar 2009 at 7:12

[GoogleCodeExporter]

The 'large alloc' warnings are coming because 'static int64_t 
large_alloc_threshold'
(tcmalloc.cc) is == 0 at the time these mallocs are occuring, which is during 
static
initialization time before main.  

Specifically, the gflags DEFINE_string() in various files in tcmalloc causes 
STL to
initialize a pool for basic_string, which triggers the mallocs.  For me, the
mallocs() during static-init-time tend to be either 36864 (9 pages) or 65536 
(16 pages).

I propose this patch -- the extra (and well predictable) branch shouldn't affect
performance in a function that already needs to get more pages, I'd imagine.

--- /home/mrabkin/gperftools/google-perftools-1.1/src/tcmalloc.cc   2009-03-03
11:52:18.000000000 -0800
+++ tcmalloc.cc 2009-03-30 11:25:29.085659000 -0700
@@ -598,7 +598,7 @@
     SpinLockHolder h(Static::pageheap_lock());
     span = Static::pageheap()->New(num_pages);
     const int64 threshold = large_alloc_threshold;
-    if (num_pages >= (threshold >> kPageShift)) {
+    if (threshold && num_pages >= (threshold >> kPageShift)) {
       // Increase the threshold by 1/8 every time we generate a report.
       // We cap the threshold at 8GB to avoid overflow problems.
       large_alloc_threshold = (threshold + threshold/8 < 8ll<<30

Original comment by mrab...@gmail.com on 30 Mar 2009 at 6:26

[GoogleCodeExporter]

I like both fixes.  They'll be in the next tcmalloc release.

Original comment by csilv...@gmail.com on 30 Mar 2009 at 11:11

• Changed state: Started

[GoogleCodeExporter]

Original comment by csilv...@gmail.com on 30 Mar 2009 at 11:19

• Added labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

This should be fixed in perftools 1.2, just released.  I also threw in a fix for
cygwin, which had tricky issues involving the .exe extension.

Original comment by csilv...@gmail.com on 18 Apr 2009 at 12:12

• Changed state: Fixed