|
From: WAROQUIERS P. <phi...@eu...> - 2011-08-31 09:40:33
|
>With valgrind, the memory footprint is increased, and the allocation
>does eventually fail. The footprint increase is caused, as I
>understand it, by valgrind keeping alive blocks that would normally be
>freed during realloc, so that it can check for accesses to those
>blocks. In any case, the only relevant fact is that the footprint
>increases for the grow-by-realloc usage model, and can increase
>drastically.
Note that if the default value for the free list volume is used,
(what you call the "keeping alive blocks"), then this is not the
cause of huge memory footprint, as the default size of this free list
volume is rather small (20 Mb).
The memory footprint is increased due to various factors:
1. the V-bit machinery of Valgrind/memcheck
2. the additional overhead of the Valgrind malloc replacement
compared to the libc malloc.
3. the free list ("alive blocks") of memcheck
4. Valgrind malloc replacement fragmentation when doing reallocation
of big pieces of memory. (see bug 250101).
5. other aspects (e.g. some other memory used internally by
Valgrind).
I think that 1 and 2 are somewhat proportional to the memory used by
a "native" execution.
3 is under user control, default value is rather small.
4 can however cause quadratic memory usage (see bug 250101).
In your case, I believe it was the factor 4 that caused the problem.
Waiting for a (enhanced) fix for 250101 (on which I am working),
realloc patterns should be avoided.
Philippe
____
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.
|
|
From: John R. <jr...@bi...> - 2011-03-31 18:26:05
|
> I get the same sort of "set address range perms" I get on my real program (please, if somebody could give me more info about those, it would be helpful).
> ==12544== Warning: set address range perms: large range [0x13dde030, 0x31382050) (noaccess)
RTFM: "Diagnostic message, mostly for benefit of the Valgrind
developers, to do with memory permissions."
Valgrind gives such a message whenever the byte length [here length=0x31382050,
base=0x13dde030; notice the square bracket on the left and the round bracket
on the right] exceeds some lower bound such as 256MB. The reason is that
such a large range is most unusual, and may indicate an error.
--
|
|
From: WAROQUIERS P. <phi...@eu...> - 2011-04-01 13:35:36
|
I digged a little bit at your problem (using a valgrind patched with gdbserver): I put a break at line 83, then searched the leaks and examined the value of m14. Then did "next", and again searched leaks and examined value of m14. And then the same for the next line. You will see then that the realloc at line 85 (and following) are all failing. I suspect the realloc fails due to Valgrind malloc replacement being unfriendly to "realloc" usage pattern. As the realloc at line 85 fails, the "m14" block last allocated is at line 84. The m14 value is then replaced by NULL at line 85 (which means that the free(m14) does not free anything). I suggest you look at the following bug (and attached patch): https://bugs.kde.org/show_bug.cgi?id=250101 Note that the problem I encountered was not with realloc, but with "free" followed by "malloc" of a bigger block. But I suppose this matches pretty well your problem. And of course, feel free to try the gdbserver patch: https://bugs.kde.org/show_bug.cgi?id=214909 (any feedback, in particular on the user manual, will be welcome.). Philippe ____ 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. |