Top «Prev(2007-10-22) Latest Next(2007-10-27)» Edit

pterjan's diary


2007-10-24

  Perl/PHP/Python/Ruby and memory management quality

Here are the result of starting the interpreters in valgrind with an empty script : perl, php, python, ruby.

So, Ruby is OK, Perl and PHP have small memory leaks, but Python has a bunch of worrying errors including undefined behaviors and uses after free !

Of course this does not imply anything on how they manage their memory later, but I think that being clean in the simple case shows if you care about it.

Update: A Rafael wrote in the comments, Perl does not free its objects by default when the interpreter is destroyed, and even if I can't test it, running PERL_DESTRUCT_LEVEL=2 valgrind perl -e '' should not show any memory leak (if your perl was built with -DDEBUGGING). As he pointed out, perl even has a Makefile rule to run all the tests under valgrind.

Update 2: as several people pointed out, the "Use of uninitialised value" from Python are expected and harmless. Does someone have an explanation for the read after free ? :)

Today's TSUKKOMI(Total: 7) [Add a TSUKKOMI]
  lrz (2007-10-24 23:17)

<nelson-voice>haha!</nelson-voice>

  rgs (2007-10-25 08:20)

perl doesn't free its objects at interpreter destruction time, unless you tell him to do so with the environment variable PERL_DESTRUCT_LEVEL (see the perlrun(1) manpage for details). You should try again with it... The core perl developers are quite concerned with memory leaks and there's even a makefile target to run the whole test suite under valgrind and get nice reports.

  Pascal (2007-10-25 08:26)

It does not change anything but after reading the doc I think this is because my perl is not built with -DDEBUGGING.<br>I'll trust you on that and update the post :)

  Eduardo Habkost (2007-10-25 20:40)

Re Python:<br><br>http://svn.python.org/projects/python/trunk/Misc/README.valgrind<br><br>"If you use valgrind on a default build of Python, you will see many errors like:<br><br> ==6399== Use of uninitialised value of size 4<br> ==6399== at 0x4A9BDE7E: PyObject_Free (obmalloc.c:711)<br> ==6399== by 0x4A9B8198: dictresize (dictobject.c:477)<br><br>These are expected and not a problem. [...]"

  Pascal (2007-10-26 00:09)

I have read the text twice and I fail to understand why they are "not a problem".<br>From what I understand, he says that uninitialized data will always be invalid, but I think that nothing guarantees that (even if it would be very bad luck...).

  haypo (2007-10-26 15:57)

ou should read this document about how to use Valgrind with CPython:<br>http://svn.python.org/projects/python/trunk/Misc/README.valgrind<br><br>CPython uses a complex garbage collector: the collector use referrence counting + mark and sweep algorithm to detect cycles (A depend on B and B depends on A). It also uses 3 object generations. Get more informations in gc module documentation:<br>http://docs.python.org/lib/module-gc.html

  Pascal (2007-10-26 16:11)

Someone smarter than me explained me README.valgrind and indeed this should be OK :)


2004|06|07|08|09|11|
2005|01|02|05|06|07|08|09|10|11|12|
2006|01|02|03|06|08|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|12|
2011|02|04|06|
2012|01|05|11|
2013|01|02|04|06|
2014|02|
2015|06|
2017|05|07|12|