Initial mmap hook prevents heap profiler to profile mmap()s

[Google Code Exporter]

What steps will reproduce the problem?
1. do not specify HEAPPROFILE for the profiler to start automatically
2. start the profiler manually

What is the expected output? What do you see instead?
The program should run and get profiled, however this was not true.

What version of the product are you using? On what operating system?
V1.3 on Linux.

Please provide any additional information below.
When setting the hook, return NULL if the old hook was the initial hook
should work.

Original issue reported on code.google.com by [e-mail] on 30 Aug 2009 at 11:47

[Google Code Exporter]

I'm not quite sure I understand the proposed solution.  Can you maybe provide a 
patch
(a verbal description of line numbers to change and what to change them to 
would be
fine) to illustrate what you mean?

Original comment by [e-mail] on 31 Aug 2009 at 5:37

• Added labels: Priority-Medium, Type-Defect

[Google Code Exporter]

Hmm, after trying to reproduce the problem, I realized that it is only 
problematic
when you link libtcmalloc statically. And there was no mmap() calls before 
starting
the profiler, so the initial hook was not reset. I guess the module initializers
don't get called for static libraries.

The patch is attached. It is quite simple. Just testing to see if the old hook 
is the
initial one, and if it is, considered it a NULL hook.

Original comment by [e-mail] on 1 Sep 2009 at 2:20

Attachments:

• mmap-hook.patch

[Google Code Exporter]

Ah, looking back at the problem description, I see that I did not describe the
problem clearly. The reproduction steps should be:

1. link libtcmalloc.a statically to the program;
2. do not specify HEAPPROFILE for the profiler to start automatically;
3. specify HEAP_PROFILE_MMAP=true for the profiler to profile mmap() calls;
4. start the profiler manually by calling HeapProfilerStart().

And the actual output was a line saying:

Had other mmap/mremap/munmap/sbrk MallocHook-s set. Make sure only one of
MemoryRegionMap and the other client is active.

And a core dump.

P.S.: I thought the attached textual patch would get inlined in the comment, 
but it
was not. I would manually inline the very simple patch myself here:

diff -ru ./src/malloc_hook.cc ../google-perftools-1.3/src/malloc_hook.cc
--- ./src/malloc_hook.cc    2009-09-01 10:11:40.000000000 +0800
+++ ../google-perftools-1.3/src/malloc_hook.cc  2009-06-09 06:52:26.000000000 
+0800
@@ -168,11 +168,7 @@

 extern "C"
 MallocHook_MmapHook MallocHook_SetMmapHook(MallocHook_MmapHook hook) {
-  MallocHook_MmapHook old_hook = mmap_hook_.Exchange(hook);
-  if (old_hook == InitialMallocHook_MMap)
-    return NULL;
-  else
-    return old_hook;
+  return mmap_hook_.Exchange(hook);
 }

 extern "C"

Original comment by [e-mail] on 1 Sep 2009 at 2:27

[Google Code Exporter]

Hmm, I'm having trouble reproducing this.  Here is my test program, 
/var/tmp/test.cc:
---
#include "google/heap-profiler.h"

void leak_some_memory() {
  for (int i = 0; i < 1000000; i++)
    new int;
}

int main(int argc, char *argv[])
{
  HeapProfilerStart("/var/tmp/hp");
  leak_some_memory();
  HeapProfilerStop();
  return 0;
}
---

I compiled it like this, from the top of my perftools build tree:
   g++ -Isrc -g /var/tmp/test.cc .libs/libtcmalloc.a
(you could probably also do g++ -g /var/tmp/test.cc /usr/lib/libtcmalloc.a if 
you
have perftools installed).

I then did
   env HEAP_PROFILE_MMAP=true ./a.out

and the program ran successfully.

Can you reproduce this problem with this setup?

Original comment by [e-mail] on 1 Sep 2009 at 11:33

[Google Code Exporter]

Any more word on this?  It would be great to understand this problem better.

Original comment by [e-mail] on 14 Oct 2009 at 11:25

[Google Code Exporter]

Alas, me either.  I'm going to close the bug CannotReproduce.

Original comment by [e-mail] on 10 Mar 2010 at 6:17

• Changed state: CannotReproduce

[Google Code Exporter]

I was able to reproduce the problem as per comment 3.  The patch works for me 
too.

Original comment by [e-mail] on 21 Oct 2009 at 4:41

[Google Code Exporter]

I'm glad you were able to reproduce it.  I'd still like to understand what's 
going on
better.  For instance, why do we only need to patch the NewHook?  Might this 
same
problem affect the other hooks as well?

Can you give a attach a simple program that reproduces this problem, along with
instructions on how you built and ran the program in order to get the error?

Original comment by [e-mail] on 21 Oct 2009 at 5:09

[Google Code Exporter]

Sorry, I can no longer reproduce the problem.

Original comment by [e-mail] on 29 Oct 2009 at 11:56