Thanks. Sounds like a nice way to allow a bigger free list volume and it would
have helped in my case. I'll just wait for the 3.7 release since I already
fixed this bug. But I would still love to see Valgrind get rid of the 32G limit.
Thanks,
Meir
________________________________
From: WAROQUIERS Philippe [mailto:[email protected]]
Sent: Friday, October 14, 2011 4:00 PM
To: Yeshurun, Meir; [email protected]
Subject: RE: [Valgrind-users] --free-list-vol limit
I think it is not possible (or at least without significant work) to overcome
the 32Gb limit.
An alternative solution might be:
if you have a mixture of big allocations and small allocations in your
application,
and your double free is of a "small" size,
then you could take a 3.7.0 from SVN (see
http://www.valgrind.org/downloads/repository.html )
and apply the patch in bugzilla http://bugs.kde.org/show_bug.cgi?id=250065
With this patch, you have a new option --freelist-big-blocks=....
which allows to specify the size above which
the blocks are "released" from the free list in priority.
With this, you might "prune" parts of the big alloc/free from the free list,
allowing you
to find the double free of your "small" block.
Philippe
________________________________
From: Yeshurun, Meir [mailto:[email protected]]
Sent: Friday 14 October 2011 15:31
To: [email protected]
Subject: [Valgrind-users] --free-list-vol limit
Hi,
I recently had to debug a double free. This could have been a piece of cake
with Valgrind, but unfortunately the first and second frees were a few minutes
of runtime apart, so all I got was the "address was not recently malloc()ed..."
message instead of the backtrace corresponding to the first free.
When I increased the -free-list-vol to the maximum value allowed by Valgrind,
Valgrind aborted prematurely, apparently because the 32G memory limit was
reached. My machine had 96G, and I'm sure it would have been enough for
obtaining the backtrace of the first free.
Is it possible to overcome the 32G limit? I don't think machines with more
memory than that are rare.
Thanks,
Meir
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
____
This message and any files transmitted with it are legally privileged and
intended for the sole use of the individual(s) or entity to whom they are
addressed. If you are not the intended recipient, please notify the sender by
reply and delete the message and any attachments from your system. Any
unauthorised use or disclosure of the content of this message is strictly
prohibited and may be unlawful.
Nothing in this e-mail message amounts to a contractual or legal commitment on
the part of EUROCONTROL, unless it is confirmed by appropriately signed hard
copy.
Any views expressed in this message are those of the sender.
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
