When turning on the low-level interpreter tracing feature (lltrace in ceval.c) it is quite easy to hit infinite recursion in dump_stack(), when an item on the stack being printed has a __repr__ method implemented in Python. (This is especially annoying when hardcodinglltrace = 1, since it will never get through the importlib bootstrap -- for some reason the __repr__ for module objects is (re-)implemented in Python.)
While I suppose we could fix this by adding some kind of protection against recursive calls to dump_stack(), I think it's better to just avoid calling into Python at all by writing most objects in the form <type at address> (with exceptions for ints etc.).
CC @sweeneyde, author of dump_stack() in gh-91463. (I don't want to just remove it -- it actually saved my bacon today.)
Linked PRs
When turning on the low-level interpreter tracing feature (
lltracein ceval.c) it is quite easy to hit infinite recursion indump_stack(), when an item on the stack being printed has a__repr__method implemented in Python. (This is especially annoying when hardcodinglltrace = 1, since it will never get through the importlib bootstrap -- for some reason the__repr__for module objects is (re-)implemented in Python.)While I suppose we could fix this by adding some kind of protection against recursive calls to
dump_stack(), I think it's better to just avoid calling into Python at all by writing most objects in the form<type at address>(with exceptions for ints etc.).CC @sweeneyde, author of
dump_stack()in gh-91463. (I don't want to just remove it -- it actually saved my bacon today.)Linked PRs