GH-100987: Allow non python frames in frame stack.#103010
GH-100987: Allow non python frames in frame stack.#103010markshannon wants to merge 8 commits intopython:mainfrom
Conversation
…ill allow non-code objects in frames for better introspection of C builtins and extensions.
|
|
||
| def _f_code(self): | ||
| return self._f_special("f_code", PyCodeObjectPtr.from_pyobject_ptr) | ||
| return self._f_special("f_executable", PyCodeObjectPtr.from_pyobject_ptr) |
There was a problem hiding this comment.
Can we instead use self._f_executable here, test the type, and raise an explicit exception (or return None?) if it is not a code object?
There was a problem hiding this comment.
All uses of this function should know that self._f_executable or be guarded against it not being.
| pnames = self.co.field('co_localsplusnames') | ||
| self.co_localsplusnames = PyTupleObjectPtr.from_pyobject_ptr(pnames) | ||
| try: | ||
| self.co = self._f_code() |
There was a problem hiding this comment.
It would be better to get a clear signal right here and bail out as needed, than to have a blanket try/except around this entire section.
There was a problem hiding this comment.
Because this code runs inside gdb and there seems to be no way to see into the embedded Python interpreter, it is really hard to debug and experiment with. I'm reluctant to make any changes beyond the minimum to make it work.
| #define CONSTS() ((PyCodeObject *)frame->base.f_executable)->co_consts | ||
| #define NAMES() ((PyCodeObject *)frame->base.f_executable)->co_names |
There was a problem hiding this comment.
any particular reason not to use _PyFrame_GetCode here?
|
Doing this enables us to remove then need for fake code objects for shims. We can just set the |
|
I'm closing this for now. |
3 participants
Inserting frames for builtin methods, method descriptors and other similar C callables into the frame stack can improve profiling and debugging.
Better still it can be done at very low cost.