For the alloc'd line Valgrind points at new_allocator.h line 110, the
de-alloc line is pointed to new_allocator.h line 104. The first looks like
this in GCC sources:
return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp)));
the second looks like this:
deallocate(pointer __p, size_type)
{ ::o
On Thu, 2015-06-11 at 18:19 +0800, 王阳 wrote:
> --28682-- univ_laog_do_GC enter cardinality 9614
> --28682-- univ_laog_do_GC exit seen 6591 next gc at cardinality 9615
yes, one of the things that --stats=yes activates is some information
about laog GC.
>
> why?
> DRD have not that problem ,but DRD
On Thu, 2015-06-11 at 12:14 +0200, Julian Seward wrote:
> > I've recently switched over to Valgrind 3.10.1 and I'm now see vast numbers
> > of 'mismatched free/delete' type messages all coming from std::string
> > shipped with GCC 4.8.3.
Do you see these 'mismatches free/delete' only with Valgrind
> One question to you: does it make sense to be hard-coding the *0x3001*
> case into the generalioctl handler, or should there be an NVIDIA-specific
> file in the coregrind/m_syswrap directory?
There is already a mechanism for dealing with proprietary GPU ioctls,
because of the need to run on
Julian Seward wrote:
> One other option is to play around with optimisation settings for your app,
> to see if it changes g++'s inline/no-inline decisions.
g++'s -fno-inline option may help, although it has the same limitation of not
applying to libraries.
--
John Dallman
-
Sie
Hi.
I download the latest version 3.10.1,but helgrind use memory over 64G and got a
error from valgrind because of over the momory limit.
I used the option --stats=yes, I noticed that valgrind print message below
endless util to use 64G memory.
--28682-- univ_laog_do_GC enter cardinality 9
> I've recently switched over to Valgrind 3.10.1 and I'm now see vast numbers
> of 'mismatched free/delete' type messages all coming from std::string
> shipped with GCC 4.8.3.
I've seen this a lot in the past year when working with Firefox. I believe
that it is due to what you could call "differ
- Original Message -
>
> Hi,
>
> I've recently switched over to Valgrind 3.10.1 and I'm now see vast
> numbers of 'mismatched free/delete' type messages all coming from
> std::string shipped with GCC 4.8.3.
>
> I really don't believe what Valgrind is saying but I'd like to be
> certain.
