gh-107758: Improvements to lltrace feature #107757
Conversation
- Don't call Python __repr__ in debug_stack(), to avoid recursion - Remove the comment warning against dump_stack() - Add lltrace_resume_frame() call when resuming after exception_unwind - Set lltrace when $PYTHONUOPSDEBUG >= 4
gvanrossum
changed the title
|
I'm on mobile at the moment, but this change makes sense conceptually to make sure the lltrace output isn't causing any issues during debugging (debugging is hard enough already!). I haven't played around much with the uops yet, so I can't say much about the change to add the lltrace output to the uop tracing. Also, I think I do remember wanting to print out list-of-primitive or tuple-of-primitive, but I don't remember the context. That could always be added back later if needed. |
Yeah, that would be more complicated than I feel like doing ATM (probably requiring a helper function -- and what to do about nesting those). I'll just merge this, so I can move forward with the PR that depends on it. |
|
Thanks! |
4 participants
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>.stderr, while the one inceval.cwrites tostdout; I changed the uops to write to stdout as well.CC @sweeneyde because you added
dump_stack(), @brandtbucher because you mentioned being baffled by the recursion.__repr__#107758