llvm dev - Apr 2014 - [LLVMdev] [RFC] [PATCH] Fix for sys::Process::GetMallocUsage() when using ptmalloc2 allocator in glibc

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Try-to-fix-the-value-returned-by-Process-GetMallocUs.patch
Type: text/x-patch
Size: 1907 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140422/26d714fb/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: malloc-test.c
Type: text/x-csrc
Size: 503 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140422/26d714fb/attachment.c>

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>

Thanks for the reply.

On 28 April 2014 20:01, Reid Kleckner <rnk at google.com>
wrote:
> 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.
I'm not sure we can always assume libc is a dynamic library. A user
can statically link to libc if they really want to. For the static
case something like libbfd could help provided the symbol table was
still around.

It seems to me whatever we do is going to incur some overhead. Calling
dlsym() sounds a little bit expensive so we might be best off doing
the test on the first call to sys::Process::GetMallocUsage() and
storing a static variable that indicates the result of the test so we
don't need to do it again on subsequent calls to GetMallocUsage().
This would mean if an application decided to change its allocator
during execution GetMallocUsage() might break but changing the
allocator during execution sounds insane anyway, so hopefully no one
does that.

-- 
Dan Liew
PhD Student - Imperial College London