This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author neologix
Recipients flox, kaifeng, neologix, pitrou
Date 2011-04-18.16:41:01
SpamBayes Score 3.9814e-08
Marked as misclassified No
Message-id <>
In-reply-to <>
> kaifeng <> added the comment:
> I added 'malloc_trim' to the test code and rerun the test with Python 2.5 / 3.2 on CentOS 5.3.  The problem still exists.

Well, malloc_trim can fail, but how did you "add" it ? Did you use
patch to apply the diff ?
Also, could you post the output of a
ltrace -e malloc_trim python <test script>

For info, the sample outputs I posted above come from a RHEL6 box.

Anyway, I'm 99% sure this isn't a leak but a malloc issue (valgrind
--tool=memcheck could confirm this if you want to try, I could be
wrong, it wouldn't be the first time ;-) ).
By the way, look at what I just found:

> Antoine Pitrou <> added the comment:
> That's an interesting thing, perhaps you want to open a feature request as a separate issue?

Memory management is a domain which belongs to the operating
system/libc, and I think applications should mess with it (apart from
specific cases) .
I don't have time to look at this precise problem in greater detail
right now, but AFAICT, this looks either like a glibc bug, or at least
a corner case with default malloc parameters (M_TRIM_THRESHOLD and
friends), affecting only RHEL and derived distributions.
malloc_trim should be called automatically by free if the amount of
memory that could be release is above M_TRIM_THRESHOLD.
Calling it systematically can have a non-negligible performance impact.
Date User Action Args
2011-04-18 16:41:04neologixsetrecipients: + neologix, pitrou, flox, kaifeng
2011-04-18 16:41:02neologixlinkissue11849 messages
2011-04-18 16:41:01neologixcreate