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()

>>1
Here's the full output: http://codepad.org/5Foh07ON

Anyway, post more valgrind'd interpreters, compilers, etc.
Let's see who are the real lazy programmers.

Ironically, Lua, for instance, doesn't leak at all (<3 Lua):


==1851== Memcheck, a memory error detector
==1851== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==1851== Using Valgrind-3.6.1-Debian and LibVEX; rerun with -h for copyright info
==1851== Command: lua test.lua
==1851==
Hello World
==1851==
==1851== HEAP SUMMARY:
==1851==     in use at exit: 0 bytes in 0 blocks
==1851==   total heap usage: 455 allocs, 455 frees, 22,536 bytes allocated
==1851==
==1851== All heap blocks were freed -- no leaks are possible
==1851==
==1851== For counts of detected and suppressed errors, rerun with: -v
==1851== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 19 from 6)


Code in question:

function main()
    print("Hello World")
end
main()

Aaand chicken scheme, which leaks like a bitch in heat:


$ valgrind csi test.scm
==1885== Memcheck, a memory error detector
==1885== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==1885== Using Valgrind-3.6.1-Debian and LibVEX; rerun with -h for copyright info
==1885== Command: csi test.scm
==1885==

CHICKEN
(c)2008-2010 The Chicken Team
(c)2000-2007 Felix L. Winkelmann
Version 4.6.0
linux-unix-gnu-x86 [ manyargs dload ptables ]
compiled 2011-05-01 on roseapple (Linux)

; loading test.scm ...
Hello World
==1885==
==1885== HEAP SUMMARY:
==1885==     in use at exit: 586,340 bytes in 2,143 blocks
==1885==   total heap usage: 2,160 allocs, 17 frees, 592,126 bytes allocated
==1885==
==1885== LEAK SUMMARY:
==1885==    definitely lost: 0 bytes in 0 blocks
==1885==    indirectly lost: 0 bytes in 0 blocks
==1885==      possibly lost: 0 bytes in 0 blocks
==1885==    still reachable: 586,340 bytes in 2,143 blocks
==1885==         suppressed: 0 bytes in 0 blocks
==1885== Rerun with --leak-check=full to see details of leaked memory
==1885==
==1885== For counts of detected and suppressed errors, rerun with: -v
==1885== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 6)


Code:

(define (main)
    (display "Hello World")
    (newline))
(main)
(exit)

Ruby, which fucks up syscalls (as if anyone is surprised that it does):


$ valgrind ruby test.rb
==1955== Memcheck, a memory error detector
==1955== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==1955== Using Valgrind-3.6.1-Debian and LibVEX; rerun with -h for copyright info
==1955== Command: ruby test.rb
==1955==
--1955-- WARNING: unhandled syscall: 340
--1955-- You may be able to write your own handler.
--1955-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--1955-- Nevertheless we consider this a bug.  Please report
--1955-- it at http://valgrind.org/support/bug_reports.html.
"Hello World"
==1955==
==1955== HEAP SUMMARY:
==1955==     in use at exit: 342,809 bytes in 7,661 blocks
==1955==   total heap usage: 7,939 allocs, 278 frees, 346,809 bytes allocated
==1955==
==1955== LEAK SUMMARY:
==1955==    definitely lost: 0 bytes in 0 blocks
==1955==    indirectly lost: 0 bytes in 0 blocks
==1955==      possibly lost: 0 bytes in 0 blocks
==1955==    still reachable: 342,809 bytes in 7,661 blocks
==1955==         suppressed: 0 bytes in 0 blocks
==1955== Rerun with --leak-check=full to see details of leaked memory
==1955==
==1955== For counts of detected and suppressed errors, rerun with: -v
==1955== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 23 from 6)


Code:

def main
    p "Hello World"
end

main

Now my alltime favourite memory fuckup: Java

Backtrace is waaaaaay too large to be posted here, instead it's posted at codepad: http://codepad.org/hZTVNElG

Code in question... is absolutely trivial:

class Hello
{
    public static void main(String args[])
    {
        System.out.println("Hello World");
    }
}

>>5
Codepad has cut off most of the stuff, so here's a new link: http://pastebin.com/RawgaguY

If I was writing an OS, I would have valgrind-like functionality built in, and if any program that isn't compiled in debug mode has a memory leak after a normal exit, it would be blocked as malware. Programs compiled with debug settings would give a helpful indication as to where the leaked memory was allocated.

==16266== Memcheck, a memory error detector
==16266== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==16266== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==16266== Command: /usr/bin/valgrind
==16266==
==16266== Warning: invalid file descriptor -1 in syscall close()
==16269==
==16269== HEAP SUMMARY:
==16269==     in use at exit: 9,716 bytes in 59 blocks
==16269==   total heap usage: 61 allocs, 2 frees, 11,788 bytes allocated
==16269==
==16269== LEAK SUMMARY:
==16269==    definitely lost: 0 bytes in 0 blocks
==16269==    indirectly lost: 0 bytes in 0 blocks
==16269==      possibly lost: 0 bytes in 0 blocks
==16269==    still reachable: 9,716 bytes in 59 blocks
==16269==         suppressed: 0 bytes in 0 blocks
==16269== Rerun with --leak-check=full to see details of leaked memory
==16269==
==16269== For counts of detected and suppressed errors, rerun with: -v
==16269== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 6)
valgrind: no program specified
valgrind: Use --help for more information.

>>8

oh snap!


$ valgrind /usr/bin/valgrind /usr/bin/valgrind
==1346== Memcheck, a memory error detector
==1346== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==1346== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for copyright info
==1346== Command: /usr/bin/valgrind /usr/bin/valgrind
==1346==
==1346== Warning: invalid file descriptor -1 in syscall close()
==1346==
==1346== HEAP SUMMARY:
==1346==     in use at exit: 9,252 bytes in 30 blocks
==1346==   total heap usage: 32 allocs, 2 frees, 11,324 bytes allocated
==1346==
==1346== LEAK SUMMARY:
==1346==    definitely lost: 0 bytes in 0 blocks
==1346==    indirectly lost: 0 bytes in 0 blocks
==1346==      possibly lost: 0 bytes in 0 blocks
==1346==    still reachable: 9,252 bytes in 30 blocks
==1346==         suppressed: 0 bytes in 0 blocks
==1346== Rerun with --leak-check=full to see details of leaked memory
==1346==
==1346== For counts of detected and suppressed errors, rerun with: -v
==1346== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 8)
==1346== Memcheck, a memory error detector
==1346== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==1346== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for copyright info
==1346== Command: /usr/bin/valgrind
==1346==
==1346== Warning: invalid file descriptor -1 in syscall close()
==1346==
==1346== HEAP SUMMARY:
==1346==     in use at exit: 9,252 bytes in 30 blocks
==1346==   total heap usage: 32 allocs, 2 frees, 11,324 bytes allocated
==1346==
==1346== LEAK SUMMARY:
==1346==    definitely lost: 0 bytes in 0 blocks
==1346==    indirectly lost: 0 bytes in 0 blocks
==1346==      possibly lost: 0 bytes in 0 blocks
==1346==    still reachable: 9,252 bytes in 30 blocks
==1346==         suppressed: 0 bytes in 0 blocks
==1346== Rerun with --leak-check=full to see details of leaked memory
==1346==
==1346== For counts of detected and suppressed errors, rerun with: -v
==1346== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 8)
valgrind: no program specified
valgrind: Use --help for more information.

>>1
um... why have gigs of ram if you aren't going to use them?

>>7
and if any program that isn't compiled in debug mode has a memory leak after a normal exit, it would be blocked as malware

Bad idea. Sometimes, memory leaking is virtually impossible to avoid.

For example, linking against libdl.so (dlfcn.h) allocates a single, but rather small, chunk of memory that cannot be freed. That's a known bug that got never fixed.

There are many cases (among this one) where freeing memory is technically impossible.

But apart from that, leaking memory as such is not a problem; It becomes a problem when the leaked memory in question increases over time, and ends up leaking several MB (or even GB), the way Python does (which leaks 6 motherfucking MB).

As a simple rule, leaking >500kB is programmatically acceptable, since the memory gets collected by the operating system anyway, but only as long as the leaked memory STAYS below this line.

If your program leaks more memory than 500kB, something in your program is VERY broken, and you SHOULD fix it, or at least use countermeasures, like emergency garbagecollectors, or using the Boehm GC.

>>10
why herp when you can derp

I see that you fail to grasp the point of RAM. Move on, back to /g/, that is.

memory leak after a normal exit
The OS frees all the memory once the process is gone. Or are you talking about detecting memory leaks in the OS memory manager?

>>10

RAM can be used for better things, like caching files and stuff.

And yes, when a process is terminated, all the memory it was using is returned, regardless of how the program in the running processed decided to allocate data in the memory the OS gave it. So there is no point in freeing memory immediately before the program ends, for example. This type of memory leak isn't really a leak at all, since it was always in use by the program during its execution, and taking the time to free it when the program is terminating isn't needed and would only take needless time.

<script>document.body.innerHTML="";</script>

>>15
he tries to XSS on a shitchan powered board

laughing_whores.tif

>>14
I always view the memory as private resource and not as some communal service that must be freed after use.
GC model views the memory taken by objects as loans against the global pool, while manual allocation is like gifts which you give to yourself as often as you like, and only you can decide when to return or discard them.

>>17
GC model views the memory taken by objects as loans against the global pool
I wish Java subscribed to that. It views memory as the loved one of a wealthy family and holds it for ransom.

- 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

>>3,8
You know those aren't leaks, right?


static void *p;
main()
{
  p = malloc(23);
}

No leak. Just never free'd.

Objects that live as long as the entire execution of the program need not be free'd.

>>19
Ohh, because FSFE (also known as GNU), is totally known for writing wellworking code...

Wait, no, it isn't! It isn't known for writing good working code at all!

Just about any GNU/Bullshit program leaks like a faggot, and, knowing that, FSFE tries to spread FUD about valgrind.

Fuck GNU

>>20
Same fucking thing.

>>21
This is exactly what I would expect to hear from a GNU/Zealot, who write broken code all the time.

>>22,23
You don't understand how C works.

>>23
It might have been true that once, such memory may have been lost to the OS, but today's operating systems automatically free all memory after a program ends, which makes freeing memory just before exiting rather pointless.

OP, what version of python you're using?

I have
==32550== ERROR SUMMARY: 2170 errors from 111 contexts (suppressed: 4 from 4)

for python3.2.2rc1 and

==32647== ERROR SUMMARY: 829 errors from 78 contexts (suppressed: 4 from 4)

for 2.7.2+


function bestpony() {
    echo "Trixie"
}

bestpony

Look at this leakfest:


$ valgrind bash a.sh
==759== Memcheck, a memory error detector
==759== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==759== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==759== Command: bash a.sh
==759==
Trixie
==759==
==759== HEAP SUMMARY:
==759==     in use at exit: 0 bytes in 0 blocks
==759==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==759==
==759== All heap blocks were freed -- no leaks are possible
==759==
==759== For counts of detected and suppressed errors, rerun with: -v
==759== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)

>>27
your kind is not welcomed here

Datte hontō wa crazy!

>>22
You're right! CVE-2008-0166 was all an GNU conspirancy!

>>26
2.7, which is still default on many Linux distributions.

>>24
The fact that you picked "C", instead of "any language that is able to allocate/deallocate memory" pretty much shows that YOU don't understand how virtual memory works.

Wonderful.. I will bookmark your blog and take the feeds also…I am satisfied to find so much useful info here in the post. Thank you for sharing. Vogue beautiful and popular dancing party full dress, you are worth owning.
http://www.hermeshandbagoutlet.com
http://www.handbagsdreams.com
http://www.backpackunion.com
http://www.charmhandbags.com
http://www.pursehandbag.org