-
Notifications
You must be signed in to change notification settings - Fork 50
Protect against shim frames at the bottom of the stack #204
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@godlygeek we still have a problem with shim frames and native frames in general because it's possible that we are in one of these two situations (we are just returning or we are just entering) and therefore we won't identify the entry frame properly as in 3.12+ entry frames are frames preceded by shim frames but out shim frame it's at the bottom of the stack and this prevents us from merging the native stack properly |
For instance, this generates such a situation:
|
9722e2a
to
66c772f
Compare
I decided to fix the shim problem by always capturing shim frames and filter them out properly in the traceback formatter, which is slightly less efficient because we are not skipping them but thanks to the cache the overhead is minimal because the code object is always the same. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few small requests
I have amended the last commit with your requests, please take another look |
It's possible that pystack analyses a core file or a program at a specific moment where the bottom of the stack has a shim frame but a normal frame has not been pushed yet or the last normal frame has been removed because the evaluation loop is returning. In this case, we were not resolving the code object, but we are not skipping the frame either because it's the first frame. This was causing the code object pointer in the frame to be NULL but we are not checking for that condition when unwinding. Signed-off-by: Pablo Galindo <pablogsal@gmail.com>
LGTM, though I made two more tweaks to the tests:
|
It's possible that pystack analyses a core file or a program at a
specific moment where the bottom of the stack has a shim frame but a
normal frame has not been pushed yet or the last normal frame has been
removed because the evaluation loop is returning.
In this case, we were not resolving the code object, but we are not
skipping the frame either because it's the first frame. This was causing
the code object pointer in the frame to be NULL but we are not checking
for that condition when unwinding.
Closes: #199