This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients methane, pablogsal, serhiy.storchaka, vstinner
Date 2019-04-11.02:18:16
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1554949096.32.0.276665636387.issue36389@roundup.psfhosted.org>
In-reply-to
Content
bpo-33803 bug can be reintroduced using the following patch:

diff --git a/Python/hamt.c b/Python/hamt.c
index 67af04c437..67da8ec22c 100644
--- a/Python/hamt.c
+++ b/Python/hamt.c
@@ -2478,8 +2478,10 @@ hamt_alloc(void)
     if (o == NULL) {
         return NULL;
     }
+#if 0
     o->h_count = 0;
     o->h_root = NULL;
+#endif
     o->h_weakreflist = NULL;
     PyObject_GC_Track(o);
     return o;

And then run:

./python -m test -v test_context

The best would be to also be able to catch the bug in:

./python -m test -v test_asyncio

Problem: Right now, my GC object debugger implementation is way too slow to use a threshold lower than 100, whereas the bug is catched like "immediately" using gc.set_threshold(5).

Maybe my implementation should be less naive: rather than always check *all* objects tracked by the GC, have different thresholds depending on the generation? Maybe reuse GC thresholds?
History
Date User Action Args
2019-04-11 02:18:16vstinnersetrecipients: + vstinner, methane, serhiy.storchaka, pablogsal
2019-04-11 02:18:16vstinnersetmessageid: <1554949096.32.0.276665636387.issue36389@roundup.psfhosted.org>
2019-04-11 02:18:16vstinnerlinkissue36389 messages
2019-04-11 02:18:16vstinnercreate