[LLVMdev] [RFC] [PATCH] Fix for sys::Process::GetMallocUsage() when using ptmalloc2 allocator in glibc

[Reid Kleckner]

The problem with tcmalloc seems like a real problem.  I can't think of any
good workarounds.  My best worst idea is to try to figure out if malloc is
coming from libc with dlsym and dlopen, and then use that to decide whether
we add these two numbers together.


On Tue, Apr 22, 2014 at 6:34 AM, Dan Liew <dan at su-root.co.uk> wrote:

> Hi,
>
> This is a proposed fix for bug 16847 [1]. It is essentially the patch
> provided by Martin Nowack in the bug report but I have added a test
> case and an ifdef macro around the modified code in
> Process::GetMallocUsage()
>
> The issue seems to be that the ptmalloc2 allocator used in glibc (in
> my case 2.19) does not include mmap()'ed memory in mallinfo.uordblks
> and so mallinfo.hblkhd needs to be added to the value that
> Process::GetMallocUsage() will return.
>
> Another easy way to see this issue (other than running the unit test)
> is to build and run the attached "malloc-test.c" program on a system
> that uses glibc. You will see that after malloc'ing 256MiB of memory
> uordblks is still zero but hblkhd has increased.
>
> This is an RFC because I'm not very happy with my use of...
>
> #if defined(__GLIBC__)
>
> This will work in the common case where glibc is being used with its
> standard allocator. However it will completely fail in the case where
> LLVM is being used as a library and a developer chooses to use a
> different allocator. For example if tcmalloc [2] is used then the
> calculation is wrong[3] because mallinfo.uordblks includes mmap()'ed
> memory and so we would count mmap()'ed memory twice!
>
> Thoughts?
>
> [1] http://llvm.org/bugs/show_bug.cgi?id=16847
> [2] http://goog-perftools.sourceforge.net/doc/tcmalloc.html
> [3] https://github.com/klee/klee/pull/116
>
> Thanks,
> --
> Dan Liew
> PhD Student - Imperial College London
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140428/61b301be/attachment.html>