Closed mattp- closed 4 years ago
by the way, despite this issue your tool just helped me isolate a huge performance bug on production in a matter of minutes. amazingly useful! thank you for it 👍
Thanks for the bug report!
I just spent some time looking at this and I think I've found a minimal reproduction here. Trying to go dump --locals
with a function looking like this will fail with the same error you reported:
def local_variable_lookup():
local6 = ("-" * 115, {"key" : {"key": {"key":"value"}}})
time.sleep(100000)
It requires a somewhat specific set of circumstances: nested objects at least two deep with the innermost objects being strings and some previous variable that has a string representation of the correct length. This manages to blow through the code that's trying to limit the length of a line - and cause us to try to slice off a negative amount from a string causing the panic you saw.
I have a fix here https://github.com/benfred/py-spy/pull/225 .
I'm glad that py-spy is coming in useful - even with this bug. The fix will be in the next version.
@benfred not entirely familiar with rust, just wondering if it would be possible on a stacktrace panic to ensure regardless that the target process receives a sigcont? I accidentally left a process in a sigstop state when this happened.
The process should be resumed even after a panic already: I'm not sending a SIGSTOP to pause it, but instead I'm doing a ptrace attach. The corresponding ptrace detach takes place inside a drop trait, which should get called during the panic.
What OS are you running? I just tried this on OSX and linux, and the process wasn't left stopped after causing a panic in py-spy using that code above.
Fix for the panic is in v0.3.3
im not actually sure, i tried reproducing but wasn't able to. going to close this since it was fixed 👍 thanks
not sure how to provide more information here, dump without --locals works. Im pointing it at a tornado app.