[issue28653] refleak in functools.lru_cache

Ivan Levkivskyi added the comment: Anyway, this is not urgent, typing.py uses the default version, which is the C version. -- ___ Python tracker ___

[issue28653] refleak in functools.lru_cache

Yury Selivanov added the comment: > It seems to be unrelated to typing.py Wow. I can reproduce refleaks in test_typing, but not in test_functools. This is weird. -- ___ Python tracker

[issue28653] refleak in functools.lru_cache

Changes by Yury Selivanov : -- stage: commit review -> needs patch ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue28653] refleak in functools.lru_cache

Yury Selivanov added the comment: > Anyway, this is not urgent Not so sure, a refleak in pure-python version kind of scares me. It can be a bug in the core. -- ___ Python tracker

[issue28653] refleak in functools.lru_cache

Ivan Levkivskyi added the comment: > Wow. I can reproduce refleaks in test_typing, but not in test_functools. This > is weird. Indeed, I copied the new test from test_functools to test_typing, but now I see that pure Python version of lru_cache fails even if I remove this test and test that w

[issue28653] refleak in functools.lru_cache

Ivan Levkivskyi added the comment: I am not sure what does this mean, but when I remove __slots__ = () from some classes, numbers of leaked references change. -- ___ Python tracker

[issue28653] refleak in C functools.lru_cache

Yury Selivanov added the comment: Ivan, I think I figured it out, I'll close this one and reopen the typing one. -- resolution: -> fixed stage: needs patch -> resolved status: open -> closed title: refleak in functools.lru_cache -> refleak in C functools.lru_cache _

[issue28649] refleak in typing.py

Yury Selivanov added the comment: So Ivan made an interesting observation: if we use Python version of functools.lru_cache, typing tests start to leak like crazy: beginning 6 repetitions 123456 .. test_typing leaked [24980, 24980, 24980] references, sum=74940 I experimented

[issue28649] refleak in typing.py

Guido van Rossum added the comment: But why is this so different from the C implementation of lru_cache? -- ___ Python tracker ___ ___

[issue28649] refleak in typing.py

Yury Selivanov added the comment: > But why is this so different from the C implementation of lru_cache? I don't know. Maybe C version of lru cache creates a bit less pressure on GC. BTW, if I set maxsize=10 for typing lru_cache, test_generic_forward_ref crashes in refleak-test mode. Mayb

[issue28649] refleak in typing.py

Yury Selivanov added the comment: >> But why is this so different from the C implementation of lru_cache? > I don't know. Maybe C version of lru cache creates a bit less pressure on GC. Actually test/refleak.py now cleans up typing's lru cache & calls "gc.collect()". It seems that the typing

[issue28649] refleak in typing.py

Guido van Rossum added the comment: Segfault or traceback? Anyway, it implements a doubly-linked list where each node is implemented as a list of 4 items... Maybe there's something in the GC code that recurses down at the C level??? I'm not sure a crash the Python version of lru_cache with maxsi

[issue28649] refleak in typing.py

Ivan Levkivskyi added the comment: > * It looks like that some types in the cache are being *reused* by different > tests. I also noticed this some time ago, ideally we need to make all tests more isolated between each other. > Now this all of this is just my guess of what's going on here.

[issue28649] refleak in typing.py

Yury Selivanov added the comment: > Segfault or traceback? Traceback. I should have said failed, not crashed :( > I'm not sure a crash the Python version of lru_cache with maxsize=10 is high on my list of worries. The problem is that the test fails depending on cache size, and caching code

[issue28649] refleak in typing.py

Ivan Levkivskyi added the comment: It looks like the tearDown() works really well. It also somehow fixes the problem with test_generic_forward_ref -- ___ Python tracker ___

[issue28649] refleak in typing.py

Ivan Levkivskyi added the comment: I think Yury is right here. The good plan would be to add the tearDown(), but also fix the problem with test_generic_forward_ref. I could work on it tomorrow (really don't have time today, sorry). -- ___ Python tra

[issue28615] Document clarification: Section 5.4 Complex Number

Mariatta Wijaya added the comment: Hi, here is the doc update, to be applied to 2.7 branch. Please review. Thanks :) -- keywords: +patch nosy: +Mariatta Added file: http://bugs.python.org/file45418/issue28615.patch ___ Python tracker

[issue23839] Clear caches after every test

Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file45419/regrtest_clear_caches_3.patch ___ Python tracker ___ ___ Python-bug

[issue24329] __qualname__ and __slots__

Changes by Xiang Zhang : -- keywords: +patch stage: -> patch review type: -> behavior Added file: http://bugs.python.org/file45420/slots_qualname.patch ___ Python tracker ___ _

<    1   2