On Fri, Apr 15, 2016 at 09:38:03AM +0200, Ivo Raisr wrote:
> 2016-04-15 2:56 GMT+02:00 John Reiser <jrei...@bitwagon.com>:
> > ===== massif/tests/new-cpp.post.diff   (post)
> > -  1          4,008            4,008            4,000             8
> >     0
> > -  2          8,016            8,016            8,000            16
> >     0
> > -  3         10,024           10,024           10,000            24
> >     0
> > -  4         12,032           12,032           12,000            32
> >     0
> > -  5         12,032           12,032           12,000            32
> >     0
> > -99.73% (12,000B) (heap allocation functions) malloc/new/new[],
> > --alloc-fns, etc.
> > -->33.24% (4,000B) 0x........: main (new-cpp.cpp:19)
> > +  1         72,712           72,712           72,704             8
> >     0
> > +  2         76,720           76,720           76,704            16
> >     0
> > +  3         80,728           80,728           80,704            24
> >     0
> > +  4         82,736           82,736           82,704            32
> >     0
> > +  5         84,744           84,744           84,704            40
> >     0
> > +  6         84,744           84,744           84,704            40
> >     0
> > +99.95% (84,704B) (heap allocation functions) malloc/new/new[],
> > --alloc-fns, etc.
> > +->85.79% (72,704B) 0x........: ??? (in /usr/lib64/libstdc++.so.6.0.21)
> > +| ->85.79% (72,704B) 0x........: call_init.part.0 (dl-init.c:72)
> > +|   ->85.79% (72,704B) 0x........: _dl_init (dl-init.c:30)
> > +|     ->85.79% (72,704B) 0x........: ??? (in /usr/lib64/ld-2.21.so)
> > +|
> > +->04.72% (4,000B) 0x........: main (new-cpp.cpp:19)
> >
> > I believe that this change in output from massif has the same underlying
> > cause
> > as the change above in the output from memcheck.
> >
> 
> Agreed. I tried to fix this in bug 345307 ignoring allocations
> done by _GLOBAL__sub_I_eh_alloc.cc. This worked for Linux/Ubuntu 15.10
> and Solaris 12. Apparently on this distribution, things are a bit different
> so another
> function needs to be ignored. A little investigation should show what needs
> to be done here.

The issue I believe is that unless we have the full symtab (from the
separate libstdc++-debuginfo package) we don't know the name of the
function. For memcheck the following suppression seems to work, with
a variant that is stripped and one with full symtab debug symbols:

{
   malloc-leaks-cxx-stl-string-classes
   Memcheck:Leak
   match-leak-kinds: reachable
   fun:malloc
   obj:*/*lib*/libstdc++.so*
   fun:call_init.part.0
   fun:call_init
   fun:_dl_init
   obj:/usr/*lib*/ld-2.*.so
}

{
  malloc-leaks-cxx-stl-string-classes-debug
  Memcheck:Leak
  match-leak-kinds: reachable
  fun:malloc
  fun:pool
  fun:__static_initialization_and_destruction_0
  fun:_GLOBAL__sub_I_eh_alloc.cc
  fun:call_init.part.0
  fun:call_init
  fun:_dl_init
  obj:/usr/*lib*/ld-2.*.so
}

I don't know how to do a similar dual suppression using the massif
--ignore-fn option.

Cheers,

Mark

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Reply via email to