The lltrace feature can trigger infinite recursion via __repr__
#107758
Labels
type-bug
An unexpected behavior, bug, or error
Comments
gvanrossum
added a commit
that referenced
this issue
Aug 8, 2023
- The `dump_stack()` method could call a `__repr__` method implemented in Python, causing (infinite) recursion. I rewrote it to only print out the values for some fundamental types (`int`, `str`, etc.); for everything else it just prints `<type_name @ 0xdeadbeef>`. - The lltrace-like feature for uops wrote to `stderr`, while the one in `ceval.c` writes to `stdout`; I changed the uops to write to stdout as well.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
The text was updated successfully, but these errors were encountered: