A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2001-December/018933.html below:

[Python-Dev] update on memory leaks in 2.2

[Python-Dev] update on memory leaks in 2.2 [Python-Dev] update on memory leaks in 2.2Fredrik Lundh fredrik@pythonware.com
Sun, 9 Dec 2001 11:04:17 +0100
guido wrote:
> I don't think so.  Insure (uselessly) lists *all* memory that's still
> allocated and reachable at exit.  Purify only reports certain blocks
> (in this case they were a bunch of weak refs) as potentially leaked.
> I'm not sure what makes them potentially leaked, but it must be a
> stronger condition than "still exists at exit".

purify runs a garbage collection algorithm on your program
to figure out if something has leaked.

iirc, a potential memory leak is when you no longer have a
pointer to the beginning of an allocated block, but there's a
valid pointer to somewhere inside the block.

a true leak is when you no longer point to the block (i.e when
even a conservative garbage collector could safely destroy it).

</F>





RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4