[Neal Norwitz]
> test_long_future:
> there are memory leak problems with binary operations
> which use longs and future division:
>
> the following code leaks 32 bytes:
>
> >>> from __future__ import division
> >>> 5L / 3L
However,
from __future__ import division
while 1:
5L / 3L
can run all day without memory size increasing, so this "leak" is probably
bogus (note that Python stores pointers to all sorts of malloc'ed memory
into file-static vrbls, and tiny "leaks" are often-- at considerable
cost --traced simply to that, e.g., a static Python string object constant
got dynamically initialized).
OTOH, if I change the tail end of test_long_future.py to
while 1:
test_true_division()
it leaks like a sieve, so *something* is wrong there. I'll track it down;
the routines that show up at the top of the stack traces appear to be
blameless:
> malloc [rtlib.o]
> muladd1 [longobject.c:51]
> PyLong_FromString [longobject.c:1027]
> parsenumber [compile.c:1096]
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