[issue6990] threading.local subclasses don't cleanup their state and it gets recycled

Antoine Pitrou added the comment: Of course, I had forgotten to rebuild :-/ Sorry for the noise. -- resolution: accepted -> fixed status: open -> closed ___ Python tracker ___ __

[issue6990] threading.local subclasses don't cleanup their state and it gets recycled

Antoine Pitrou added the comment: I get the following failure on py3k: test test_threading_local failed -- Traceback (most recent call last): File "/home/antoine/py3k/__svn__/Lib/test/test_threading_local.py", line 107, in test_derived_cycle_dealloc self.assertTrue(passed) AssertionError:

[issue6990] threading.local subclasses don't cleanup their state and it gets recycled

Changes by Antoine Pitrou : -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue6990] threading.local subclasses don't cleanup their state and it gets recycled

Philip Jenvey added the comment: applied in r75123-r75127, including a backport to release25-maint -- ___ Python tracker ___ ___ Pytho

[issue6990] threading.local subclasses don't cleanup their state and it gets recycled

Antoine Pitrou added the comment: The latest patch + tests looks ok to me. -- nosy: +pitrou ___ Python tracker ___ ___ Python-bugs-lis

[issue6990] threading.local subclasses don't cleanup their state and it gets recycled

Changes by Barry A. Warsaw : -- priority: -> release blocker ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue6990] threading.local subclasses don't cleanup their state and it gets recycled

Philip Jenvey added the comment: Also I've tagged this as a (potential) security issue. E.g. if a web app were affected, one user could potentially access another's data. I actually noticed it in the Beaker sessioning/caching middleware (used by Pylons and other web frameworks). Though it onl

[issue6990] threading.local subclasses don't cleanup their state and it gets recycled

Philip Jenvey added the comment: Great, though I think it still needs to deallocated: Index: Modules/threadmodule.c === --- Modules/threadmodule.c (revision 75050) +++ Modules/threadmodule.c (working copy) @@ -244,7 +244,

[issue6990] threading.local subclasses don't cleanup their state and it gets recycled

Amaury Forgeot d'Arc added the comment: Thanks for the excellent test case! Is seems enough to remove the statement "Py_CLEAR(self->key);" from local_clear(). self->key is a string which cannot cause cycles (and is not visited in local_traverse()); now local_dealloc() does its job. Index: threa

[issue6990] threading.local subclasses don't cleanup their state and it gets recycled

Changes by Ben Bangert : -- nosy: +bbangert ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue6990] threading.local subclasses don't cleanup their state and it gets recycled

New submission from Philip Jenvey : When threading.local subclasses are cleared during a reference cycle the local's internal key is nulled before the local is deallocated. That's a problem because local only deletes its state (ldicts) from threads during deallocation, and doesn't do so at all