ITT: Lazy

Python doesn't care about references:


==1780== Memcheck, a memory error detector
==1780== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==1780== Using Valgrind-3.6.1-Debian and LibVEX; rerun with -h for copyright info
==1780== Command: python test.py
==1780==
==1780== Invalid read of size 4
==1780==    at 0x80A9804: PyObject_Free (in /usr/bin/python2.7)
==1780==    by 0x80784F5: ??? (in /usr/bin/python2.7)
==1780==    by 0x8112064: ??? (in /usr/bin/python2.7)
==1780==    by 0x8112CB8: ??? (in /usr/bin/python2.7)
==1780==  Address 0x44ff010 is 8 bytes inside a block of size 352 free'd
==1780==    at 0x4027C02: free (vg_replace_malloc.c:366)
==1780==    by 0x43080B3: fclose@@GLIBC_2.1 (iofclose.c:88)
==1780==    by 0x62696C2E: ???
==1780==
...
<cut because it was too large for submission>
...
==1780==
==1780== Invalid read of size 4
==1780==    at 0x80A9804: PyObject_Free (in /usr/bin/python2.7)
==1780==    by 0x80784F5: ??? (in /usr/bin/python2.7)
==1780==    by 0x808C8CA: ??? (in /usr/bin/python2.7)
==1780==    by 0x8090C1D: ??? (in /usr/bin/python2.7)
==1780==    by 0x811A2E8: PyInterpreterState_Clear (in /usr/bin/python2.7)
==1780==    by 0x811C132: Py_Finalize (in /usr/bin/python2.7)
==1780==    by 0x812C55A: Py_Main (in /usr/bin/python2.7)
==1780==    by 0x805DA0A: main (in /usr/bin/python2.7)
==1780==  Address 0x4a6f010 is 3,376 bytes inside a block of size 4,370 free'd
==1780==    at 0x4027C02: free (vg_replace_malloc.c:366)
==1780==    by 0x811709F: PyMarshal_ReadLastObjectFromFile (in /usr/bin/python2.7)
==1780==    by 0x810FDCE: ??? (in /usr/bin/python2.7)
==1780==    by 0x62696C2E: ???
==1780== Invalid read of size 4
==1780==    at 0x80A9804: PyObject_Free (in /usr/bin/python2.7)
==1780==    by 0x80606D1: PyGrammar_RemoveAccelerators (in /usr/bin/python2.7)
==1780==    by 0x811C1A0: Py_Finalize (in /usr/bin/python2.7)
==1780==    by 0x812C55A: Py_Main (in /usr/bin/python2.7)
==1780==    by 0x805DA0A: main (in /usr/bin/python2.7)
==1780==  Address 0x49bb010 is 8 bytes before a block of size 303 free'd
==1780==    at 0x402896C: realloc (vg_replace_malloc.c:525)
==1780==    by 0x8064F9B: PyTokenizer_FromString (in /usr/bin/python2.7)
==1780==    by 0x8061CF5: PyParser_ParseStringFlagsFilenameEx (in /usr/bin/python2.7)
==1780==
==1780==
==1780== HEAP SUMMARY:
==1780==     in use at exit: 1,009,521 bytes in 229 blocks
==1780==   total heap usage: 6,958 allocs, 6,729 frees, 6,428,912 bytes allocated
==1780==
==1780== LEAK SUMMARY:
==1780==    definitely lost: 0 bytes in 0 blocks
==1780==    indirectly lost: 0 bytes in 0 blocks
==1780==      possibly lost: 5,684 bytes in 16 blocks
==1780==    still reachable: 1,003,837 bytes in 213 blocks
==1780==         suppressed: 0 bytes in 0 blocks
==1780== Rerun with --leak-check=full to see details of leaked memory
==1780==
==1780== For counts of detected and suppressed errors, rerun with: -v
==1780== Use --track-origins=yes to see where uninitialised values come from
==1780== ERROR SUMMARY: 754 errors from 52 contexts (suppressed: 25 from 6)


Oh, and the script in question?

def main():
    print("Hello World")

if __name__ == '__main__':
    main()

- http://svn.python.org/projects/python/trunk/Misc/README.valgrind
 - It's hardly Ruby's fault that Valgrind doesn't handle a syscall.
 - Valgrind is going to be complete garbage on a JIT compiler like Java.

Valgrind is a very helpful tool that every C programmer should know, but not all programs that pass Valgrind are correct, and correct programs can still show errors in Valgrind.
Slavishly abiding by the output of Valgrind is much like blindly driving by the GPS, and in extreme cases lead to cock-ups like http://blogs.fsfe.org/tonnerre/archives/24