You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Step into from Python to C++ doesn't work if arguments are unpacked into function call #7129
[severity:It bothers me. A fix would be nice]
It seems that in a mixed-mode Python/C++ debugging session, while debugging a piece of Python code, stepping into a function whose implementation is in C++, this does not work if the arguments are unpacked into the function call.
Example:
fast_foo(1, 2, 3) # works, I manage to step into the C++ codeargs= (1, 2, 3)
fast_foo(*args) # does not work, it instead steps over the function call
A work around seems to be to either set a break point in the C++ code, or to change the calling code:
args= (1, 2, 3)
fast_foo.__call__(*args)
For some reason, using the __call__ method seems to not suffer from the problem. However, both of these work arounds are not really satisfactory.
So basically there's some code path that handles the CALL_... bytecode opcodes that either doesn't go through any of these, or if it does, it doesn't set a breakpoint on some of the potential destinations.
Thank you for your report! While we recognize this bug is a limitation, due to our limited resources, we may not be able to prioritize this in the near term. We are going to move this to discussion and give the community 60 days to provide 7 👍 upvotes to gauge general interest. If there's enough upvotes then we will consider incorporating this in an upcoming sprint. If there's unfortunately not enough upvotes then we will close this issue. Thanks!
Activity
int19h commentedon Aug 30, 2022
Likely due to code not keeping up with various possible step-in code flows in newer versions of Python.
int19h commentedon Aug 30, 2022
Relevant code parts:
PTVS/Python/Product/Debugger.Concord/TraceManagerLocalHelper.cs
Lines 220 to 223 in 421d001
PTVS/Python/Product/Debugger.Concord/TraceManagerLocalHelper.cs
Lines 539 to 813 in 421d001
So basically there's some code path that handles the
CALL_...bytecode opcodes that either doesn't go through any of these, or if it does, it doesn't set a breakpoint on some of the potential destinations.cwebster-99 commentedon Aug 14, 2024
Thank you for your report! While we recognize this bug is a limitation, due to our limited resources, we may not be able to prioritize this in the near term. We are going to move this to discussion and give the community 60 days to provide 7 👍 upvotes to gauge general interest. If there's enough upvotes then we will consider incorporating this in an upcoming sprint. If there's unfortunately not enough upvotes then we will close this issue. Thanks!