[issue13390] Hunt memory allocations in addition to reference leaks

[Roundup Robot]

Roundup Robot added the comment:

New changeset a85673b55177 by Antoine Pitrou in branch 'default':
Following issue #13390, fix compilation --without-pymalloc, and make 
sys.getallocatedblocks() return 0 in that situation.
http://hg.python.org/cpython/rev/a85673b55177

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13390] Hunt memory allocations in addition to reference leaks

[Stefan Krah]

Stefan Krah added the comment:

Antoine Pitrou  wrote:
> Hmm, interesting. When built --without-pymalloc, we could make
> sys.getallocatedblocks() always return 0, or we could not define it all
> (which would make like a bit harder for regrtest). What do you think?

Given the name getallocatedblocks(), it would seem reasonable to return
0 in this case and document the fact. I don't think many people use
--without-pymalloc anyhow.

I'm using the option only for Valgrind testing, that's how I found
the build error.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13390] Hunt memory allocations in addition to reference leaks

[Antoine Pitrou]

Antoine Pitrou added the comment:

> sys.gettotalrefcount() is only defined when Python is compiled in
> debug mode. sys.getallocatedblocks() should only be available when
> the
> right debug option is present. This function is specific to CPython
> anyway, Python module should not rely on this (too much) ;-)

On the contrary, the aim is precisely to provide a memory statistics
function which is available for everyone, not only CPython developers.
It is simply not practical right now for a C extension developer to
check for memory leaks.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13390] Hunt memory allocations in addition to reference leaks

[anatoly techtonik]

anatoly techtonik added the comment:

Memory control over the stuff that Python creates is a practical feature that 
compensates OS disability for tracking memory usage. If all Python scripts 
could measure their memory usage, we could see more memory effective and 
adaptive programs around.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13390] Hunt memory allocations in addition to reference leaks

[STINNER Victor]

STINNER Victor added the comment:

sys.gettotalrefcount() is only defined when Python is compiled in
debug mode. sys.getallocatedblocks() should only be available when the
right debug option is present. This function is specific to CPython
anyway, Python module should not rely on this (too much) ;-)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13390] Hunt memory allocations in addition to reference leaks

[Antoine Pitrou]

Antoine Pitrou added the comment:

> ``./configure --without-pymalloc'' fails here:
> 
> gcc -pthread   -Xlinker -export-dynamic -o python Modules/python.o 
> libpython3.4.a -lpthread -ldl  -lutil   -lm  
> libpython3.4.a(sysmodule.o): In function `sys_getallocatedblocks':
> /home/stefan/hg/cpython/./Python/sysmodule.c:900: undefined reference to 
> `_Py_GetAllocatedBlocks'
> collect2: error: ld returned 1 exit status
> make: *** [python] Error 1

Hmm, interesting. When built --without-pymalloc, we could make
sys.getallocatedblocks() always return 0, or we could not define it all
(which would make like a bit harder for regrtest). What do you think?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13390] Hunt memory allocations in addition to reference leaks

[Stefan Krah]

Stefan Krah added the comment:

``./configure --without-pymalloc'' fails here:

gcc -pthread   -Xlinker -export-dynamic -o python Modules/python.o 
libpython3.4.a -lpthread -ldl  -lutil   -lm  
libpython3.4.a(sysmodule.o): In function `sys_getallocatedblocks':
/home/stefan/hg/cpython/./Python/sysmodule.c:900: undefined reference to 
`_Py_GetAllocatedBlocks'
collect2: error: ld returned 1 exit status
make: *** [python] Error 1

--
nosy: +skrah

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13390] Hunt memory allocations in addition to reference leaks

[Antoine Pitrou]

Antoine Pitrou added the comment:

Committed and pushed!

--
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13390] Hunt memory allocations in addition to reference leaks

[Roundup Robot]

Roundup Robot added the comment:

New changeset c40f4c19d20b by Antoine Pitrou in branch 'default':
Issue #13390: New function :func:`sys.getallocatedblocks()` returns the number 
of memory blocks currently allocated.
http://hg.python.org/cpython/rev/c40f4c19d20b

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13390] Hunt memory allocations in addition to reference leaks

[Antoine Pitrou]

Antoine Pitrou added the comment:

> Minor bikeshedding/spelling nit: should
>   "_Py_AllocedBlocks"
> be changed to
>   "_Py_AllocatedBlocks"
> (and s/_Py_GetAllocedBlocks/_Py_GetAllocatedBlocks/)?

Right indeed. I'll do the change.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13390] Hunt memory allocations in addition to reference leaks

[Dave Malcolm]

Dave Malcolm added the comment:

Minor bikeshedding/spelling nit: should
  "_Py_AllocedBlocks"
be changed to
  "_Py_AllocatedBlocks"

(and s/_Py_GetAllocedBlocks/_Py_GetAllocatedBlocks/)?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13390] Hunt memory allocations in addition to reference leaks

[Antoine Pitrou]

Antoine Pitrou added the comment:

Updated patch with doc. If noone objects, I will commit soon.

--
Added file: http://bugs.python.org/file28227/debugblocks6.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13390] Hunt memory allocations in addition to reference leaks

[Antoine Pitrou]

Antoine Pitrou added the comment:

As it turns out, ctypes does leak memory: see issue 16628.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13390] Hunt memory allocations in addition to reference leaks

[Antoine Pitrou]

Antoine Pitrou added the comment:

Here is an updated patch.
test_ctypes still leaks memory blocks with it:

$ ./python -m test -R 3:8 test_ctypes
[1/1] test_ctypes
beginning 11 repetitions
12345678901
...
test_ctypes leaked [2, 2, 1, 1, 1, 1, 1, 1] memory blocks, sum=10

--
nosy: +benjamin.peterson
Added file: http://bugs.python.org/file28216/debugblocks5.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13390] Hunt memory allocations in addition to reference leaks

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
versions: +Python 3.4 -Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13390] Hunt memory allocations in addition to reference leaks

[anatoly techtonik]

anatoly techtonik  added the comment:

On Mon, Dec 12, 2011 at 6:11 PM, STINNER Victor wrote:

>
> STINNER Victor  added the comment:
>
> > How different is the performance cost of this solution compared
> > to inserting DTrace probe for the same purpose?
>
> DTrace is only available on some platforms (Solaris and maybe FreeBSD?).
>

Solaris , Mac
OS X
, FreeBSD ,
NetBSD
, Oracle Linux  according to
http://en.wikipedia.org/wiki/DTrace#Supported_platforms, but that doesn't
relate to the question.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13390] Hunt memory allocations in addition to reference leaks

[Jesús Cea Avión]

Changes by Jesús Cea Avión :


--
nosy: +jcea

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13390] Hunt memory allocations in addition to reference leaks

[STINNER Victor]

STINNER Victor  added the comment:

> How different is the performance cost of this solution compared
> to inserting DTrace probe for the same purpose?

DTrace is only available on some platforms (Solaris and maybe FreeBSD?).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13390] Hunt memory allocations in addition to reference leaks

[anatoly techtonik]

anatoly techtonik  added the comment:

How different is the performance cost of this solution compared to inserting 
DTrace probe for the same purpose?

--
nosy: +techtonik

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13390] Hunt memory allocations in addition to reference leaks

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> So, I am not sure whether there really is a leak, if this is just
> a very senstive area of 'regrtest.py', or something else I am missing.

Well, test_ctypes seems to be the only test exhibiting that behaviour.
And since your script reproduces it, it's probably not regrtest.py in
itself.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13390] Hunt memory allocations in addition to reference leaks

[Meador Inge]

Meador Inge  added the comment:

I looked at the 'ctypes' "leak" a bit.  I haven't determined exactly what
is going on, but the leak has something to do with a change in the patch that
runs 'dash_R_cleanup' twice instead of once.  The new behavior can be reduced
to something like:

   import sys, ctypes, gc

   ctypes._reset_cache()
   gc.collect()

   for i in range(0, 5):
   ctypes._reset_cache()
   gc.collect()
   print("%d: start refs = %s" % (i, sys.gettotalrefcount()))
   proto = ctypes.CFUNCTYPE(ctypes.POINTER(ctypes.c_char))
   ctypes._reset_cache()
   gc.collect()
   print("%d: after refs = %s" % (i, sys.gettotalrefcount()))

which prints:

   0: start refs = 71395
   0: after refs = 71462
   1: start refs = 71463
   1: after refs = 71493
   2: start refs = 71465
   2: after refs = 71494
   3: start refs = 71465
   3: after refs = 71494
   4: start refs = 71465
   4: after refs = 71494

Note that the start/after refs converge on a difference of 29 references.

The existing version 'regrtest.py' does something like:

   import sys, ctypes, gc

   ctypes._reset_cache()
   gc.collect()

   for i in range(0, 5):
   print("%d: start refs = %s" % (i, sys.gettotalrefcount()))
   proto = ctypes.CFUNCTYPE(ctypes.POINTER(ctypes.c_char))
   ctypes._reset_cache()
   gc.collect()
   print("%d: after refs = %s" % (i, sys.gettotalrefcount()))

which prints:

   0: start refs = 71391
   0: after refs = 71458
   1: start refs = 71458
   1: after refs = 71489
   2: start refs = 71489
   2: after refs = 71490
   3: start refs = 71490
   3: after refs = 71490
   4: start refs = 71490
   4: after refs = 71490

This one converges on a difference of zero.

So, I am not sure whether there really is a leak, if this is just
a very senstive area of 'regrtest.py', or something else I am missing.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13390] Hunt memory allocations in addition to reference leaks

[Meador Inge]

Meador Inge  added the comment:

On Fri, Dec 2, 2011 at 12:12 PM, Antoine Pitrou  wrote:

> yes, c6dafa2e2594 was found with this patch. It's the only one, though 
> (there's also a leak in test_ctypes but I don't want to investigate :-)).

I'll take a look at the ctypes leak.

--
nosy: +meador.inge

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13390] Hunt memory allocations in addition to reference leaks

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> The feature is interesting, but I'm not convinced that a very simple
> counter is enough to track memory leaks. It may help the CPython test
> suite, but what about real world application?

Good question. A simple counter is the only thing we can enable by default, 
though. Anything else would require recompiling Python, which is probably a 
barrier for most users.

> Did you already found real leaks using your hack^Wpatch? (was
> c6dafa2e2594 found by your tool?)

yes, c6dafa2e2594 was found with this patch. It's the only one, though (there's 
also a leak in test_ctypes but I don't want to investigate :-)).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13390] Hunt memory allocations in addition to reference leaks

[Dave Malcolm]

Changes by Dave Malcolm :


--
nosy: +dmalcolm

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13390] Hunt memory allocations in addition to reference leaks

[STINNER Victor]

STINNER Victor  added the comment:

The overhead on PyObject_Malloc() is just an increment on an integer, so it is 
very low (or null).

The feature is interesting, but I'm not convinced that a very simple counter is 
enough to track memory leaks. It may help the CPython test suite, but what 
about real world application?

> I think we should hide at least the initial implementation
> behind PY_REF_DEBUG until we're sure we've worked the kinks
> out of it.

Programs not always behave exactly the same in debug or in release mode. 
Sometimes, bugs disappear in debug mode :-(

If the feature is written to track memory leaks in the CPython test suite, it's 
ok to only expose the function in debug mode.

> Right now this patch will allow to enrich the daily refleak runs

Did you already found real leaks using your hack^Wpatch? (was c6dafa2e2594 
found by your tool?)

--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13390] Hunt memory allocations in addition to reference leaks

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> > If someone finds a way to sanitize Valgrind output,
> 
> Did you use the valgrind suppression file (Misc/valgrind-python.supp)?

Ah, I hadn't. But using it doesn't seem to make much of a difference.
Also, the suppressions file seems quite inflexible (it has hardcoded
library version numbers for third-party libs).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13390] Hunt memory allocations in addition to reference leaks

[Charles-François Natali]

Charles-François Natali  added the comment:

> If someone finds a way to sanitize Valgrind output,

Did you use the valgrind suppression file (Misc/valgrind-python.supp)?
If yes, then one could simply use --gen-suppressions=yes to add those spurious 
warning to the suppression file.

> a daily Valgrind run would be cool as well.

Daily, or rather weakly, since running under valgrind is so much slower ;-)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13390] Hunt memory allocations in addition to reference leaks

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Valgrind does a much better job at this: it will also show you where
> the leaked blocks were allocated.
> OTOH, Valgrind is Linux-only and slow, but since I haven't used the
> '-R' option much, I don't know how usable this will be in practice
> (detecting memory leaks is one thing, identifying them is even
> better :-).

Yes, Valgrind is much more exhaustive and precise, but you have to build
Python --with-valgrind, to find the correct options to pass to Valgrind,
and also to parse the output. For example, OpenSSL seems to cause lots
of errors such as:

==20599== Conditional jump or move depends on uninitialised value(s)
==20599==at 0xA2BB0B3: BN_div (in /usr/lib64/libcrypto.so.1.0.0)
==20599==by 0xA2C125E: BN_nnmod (in /usr/lib64/libcrypto.so.1.0.0)
==20599==by 0xA2C15CD: BN_mod_mul (in /usr/lib64/libcrypto.so.1.0.0)
==20599==by 0xA2C37F0: BN_BLINDING_convert_ex
(in /usr/lib64/libcrypto.so.1.0.0)
==20599==by 0xA2E15D6: ??? (in /usr/lib64/libcrypto.so.1.0.0)
==20599==by 0x9FE6363: ssl3_get_client_key_exchange
(in /usr/lib64/libssl.so.1.0.0)
==20599==by 0x9FE83A7: ssl3_accept (in /usr/lib64/libssl.so.1.0.0)
==20599==by 0xF804190: PySSL_SSLdo_handshake (_ssl.c:390)
==20599==by 0x47C0E9: PyEval_EvalFrameEx (ceval.c:3985)
==20599==by 0x47CAC3: PyEval_EvalCodeEx (ceval.c:3376)
==20599==by 0x47B3F1: PyEval_EvalFrameEx (ceval.c:4099)
==20599==by 0x47C1DB: PyEval_EvalFrameEx (ceval.c:4089)

Right now this patch will allow to enrich the daily refleak runs (those
that send an e-mail to python-checkins). If someone finds a way to
sanitize Valgrind output, a daily Valgrind run would be cool as well.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13390] Hunt memory allocations in addition to reference leaks

[Nick Coghlan]

Nick Coghlan  added the comment:

This will likely be a decent "you have a problem" indicator, but you may still 
need tools like Valgrind to actually track down the *cause* of that problem.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13390] Hunt memory allocations in addition to reference leaks

[Charles-François Natali]

Charles-François Natali  added the comment:

> Together with -R, it can help chase those memory leaks which aren't 
> reference leaks (see c6dafa2e2594).

Valgrind does a much better job at this: it will also show you where the leaked 
blocks were allocated.
OTOH, Valgrind is Linux-only and slow, but since I haven't used the '-R' option 
much, I don't know how usable this will be in practice (detecting memory leaks 
is one thing, identifying them is even better :-).

--
nosy: +neologix

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13390] Hunt memory allocations in addition to reference leaks

[Antoine Pitrou]

Antoine Pitrou  added the comment:

And the latest patch (debugblocks3.patch) adds said heuristic.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13390] Hunt memory allocations in addition to reference leaks

[Antoine Pitrou]

Changes by Antoine Pitrou :


Added file: http://bugs.python.org/file23681/debugblocks3.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13390] Hunt memory allocations in addition to reference leaks

[Antoine Pitrou]

Changes by Antoine Pitrou :


Added file: http://bugs.python.org/file23680/debugblocks2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13390] Hunt memory allocations in addition to reference leaks

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Thanks for the comments, here is a new patch addressing them.
I've kept the C API available in all builds (since it's private), but 
sys.getallocatedblocks() is only available in debug builds.

As for the memory leak run results, I think we may have to devise a heuristic 
where results like [1,0,1] (or similar variation of 0s, 1s, and -1s) are 
considered a success, but others like [1,1,1] are a failure.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13390] Hunt memory allocations in addition to reference leaks

[Nick Coghlan]

Nick Coghlan  added the comment:

I added some review comments to the patch, but I'm not sure how usable this is 
going to be in practice. References generally stay fairly stable while using 
the interactive interpreter, but the new block accounting jumps around all over 
the place due to the internal free lists (which *don't* count in for 
'gettotalrefcounts', but *do* count in the new block accounting). The following 
interpreter session has both this patch and the #13389 patch applied:

>>> a = sys.getallocedblocks()
[76652 refs, 21773 blocks]
>>> a
21779
[76652 refs, 21774 blocks]
>>> x = [None]*1
[76652 refs, 21776 blocks]
>>> del x
[66650 refs, 21775 blocks]
>>> gc.collect(); gc.collect(); gc.collect()
0
0
0
[66650 refs, 21756 blocks]
>>> b = sys.getallocedblocks()
[66652 refs, 21772 blocks]
>>> b - a
-2
[66652 refs, 21772 blocks]

So, generally +1 on the idea, but I think we should hide at least the initial 
implementation behind PY_REF_DEBUG until we're sure we've worked the kinks out 
of it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13390] Hunt memory allocations in addition to reference leaks

[Andreas Stührk]

Changes by Andreas Stührk :


--
nosy: +Trundle

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13390] Hunt memory allocations in addition to reference leaks

[Antoine Pitrou]

New submission from Antoine Pitrou :

This patch adds a counting of the number of allocated memory blocks (through 
the PyObject_Malloc API). Together with -R, it can help chase those memory 
leaks which aren't reference leaks (see c6dafa2e2594).

The sys.getallocedblocks() function is also available in non-debug mode. This 
is meant to help 3rd party extension writers, who rarely have access to debug 
builds.

To avoid too many false positives, issue13389 is a prerequisite (at least for 
the "test -R" part of the patch). Even after it, there are still a couple "test 
-R" failures; we'd have to investigate them.

--
components: Interpreter Core, Tests
files: debugblocks.patch
keywords: patch
messages: 147531
nosy: ncoghlan, pitrou, tim_one
priority: normal
severity: normal
stage: patch review
status: open
title: Hunt memory allocations in addition to reference leaks
type: resource usage
versions: Python 3.3
Added file: http://bugs.python.org/file23671/debugblocks.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com