Bug 304346 - valgrind::memcheck doesn't seem to work with ptmalloc3
Summary: valgrind::memcheck doesn't seem to work with ptmalloc3
Status: RESOLVED DUPLICATE of bug 219156
Alias: None
Product: valgrind
Classification: Developer tools
Component: memcheck (show other bugs)
Version: 3.5.0
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-31 18:00 UTC by ZJP
Modified: 2012-08-09 06:52 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ZJP 2012-07-31 18:00:34 UTC
Our application needs some features from ptmalloc3 instead of ptmalloc2 from c library. 

The ptmalloc3 is downloaded from
   http://www.malloc.de/malloc/ptmalloc3-current.tar.gz

Using the following simple program
-----------------------------------------------
#include <stdio.h>
#include <stdlib.h>

int main()
{
    char *leak = malloc(10);

    leak[0] = 'a';
    leak = malloc(20);
    leak[0] = 'b';
}

After installing it in the system /usr/local/lib and all. Do
   gcc -g leak.c -lptmalloc3 -pthread
   valgrind --leak-check=full ./a.out

It shows no leak. If I don't use ptmalloc3, the leak shows up.
Comment 1 Philippe Waroquiers 2012-08-01 22:34:24 UTC
In valgrind 3.8.0 SVN (not yet released), the new option --soname-synonyms
allows to have Valgrind working with all libraries which implements a "classical"
malloc/free/... interface.
A.o., it has been tested with tcmalloc and jemalloc.

I suppose it will also work with ptmalloc3, adding an option like
   --soname-synonyms=somalloc=libptmalloc3*
(exact soname of ptmalloc3 lib to be checked/experimented with).

See http://www.valgrind.org/downloads/repository.html
on how to get/configure/build the not yet released last version of Valgrind.
Comment 2 ZJP 2012-08-08 20:45:33 UTC
(In reply to comment #1)
>    --soname-synonyms=somalloc=libptmalloc3*
Not quite. I sync'ed up the code from valgrind trunk. I have my library at 
/usr/local/lib/libptmalloc3.so. I tried the above string and a couple of other wildcard strings, didn't seem to work. Then I bumped into this link:
  http://blog.mozilla.org/jseward/2012/06/05/valgrind-now-supports-jemalloc-builds-directly/

I tried  "--soname-synonyms=somalloc=NONE" with valgrind trunk, it worked!

If you think this is equivalent to your suggestion, please let me know so I can "confirm" it.
Comment 3 Philippe Waroquiers 2012-08-08 22:29:54 UTC
(In reply to comment #2)
> I tried  "--soname-synonyms=somalloc=NONE" with valgrind trunk, it worked!
> 
> If you think this is equivalent to your suggestion, please let me know so I
> can "confirm" it.

If you are statically linking with libptmalloc3, NONE is the pattern to use.
If you are dynamically linking but the lib has no soname, then NONE is also ok.
Otherwise, it is recommended to use a pattern matching the soname.
The soname of the shared lib can be examined with readelf -d

If your library has such an soname and you cannot give a pattern matching
it, then that is strange.

In this case, can you give:
  the soname of your library
  the various patterns you have tried ?
Examine the output of valgrind when adding the options -d -d -d -v -v -v --trace-redir=yes 
and see if there is something that looks strange ?

Thanks
Comment 4 ZJP 2012-08-09 01:33:31 UTC
(In reply to comment #3)
> If you are statically linking with libptmalloc3, NONE is the pattern to use.
> If you are dynamically linking but the lib has no soname, then NONE is also
> ok.
That turned out to be the case. See below.

> The soname of the shared lib can be examined with readelf -d
The libptmalloc3.so was built from "make linux-shared" command recommended in the package. Running "readelf -d" on it confirmed that it is missing SONAME in its dynamic section. Your explanation above clarified it for me.

Thanks a lot for your help.
Comment 5 Philippe Waroquiers 2012-08-09 06:52:50 UTC
supported from 3.8.0 SVN onwards

*** This bug has been marked as a duplicate of bug 219156 ***