Charles-Francois Natali <neolo...@free.fr> added the comment: > kaifeng <cafe...@gmail.com> 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: http://mail.gnome.org/archives/xml/2008-February/msg00003.html > Antoine Pitrou <pit...@free.fr> added the comment: > That's an interesting thing, perhaps you want to open a feature request as a > separate issue? Dunno. 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue11849> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
