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
Skip stack unwinding when "next", "until" and "return" pdb commands executed in generator context #60800
Comments
GvR in http://mail.python.org/pipermail/python-ideas/2012-November/017991.html has requested for improving pdb to jump over yield instead of following it. |
Patch attached.
|
Thanks! I will try it out shortly. |
Rename skip_yield to skipyield |
In the test named 'test_pdb_return_command_for_generator' in the patch, the With the patch applied, in the following debugging session, pdb does not stop === bar.py === def g():
yield 0
it = g()
while True:
try:
x = next(it)
print(x)
except StopIteration:
break ================== $ ./python -m pdb /tmp/bar.py
> /tmp/bar.py(1)<module>()
-> def g():
(Pdb) break g
Breakpoint 1 at /tmp/bar.py:1
(Pdb) continue
> /tmp/bar.py(2)g()
-> yield 0
(Pdb) next
0
The program finished and will be restarted
> /tmp/bar.py(1)<module>()
-> def g():
(Pdb) ================== |
This new patch fixes the two problems described in my previous message. |
When the generator is used in a for loop, the interpreter handles the |
It looks like xdegaye's patch breaks 'n' when not debugging a generator. |
The 'until' command is also broken (by xdegaye's patch) when issued at a return This new patch fixes both problems. The patch also adds another test case to check that pdb stops after a 'next', |
I'd love it if someone could review this. This would be a great improvement to debugging coroutines in asyncio. |
I think this is not ready for inclusion. It works wonderfully when stepping over a yield[from], but I can't seem to get it to step nicely *out* of a generator. (Details on request -- basically I put a "pdb.set_trace()" call in Tulip's fetch3.py example and step around.) |
A description of what goes wrong when stepping out of the generator |
Basically the debugger lost control and the program ran to completion after I hit 'n' that returned from the coroutine. |
This is a consequence of the problem mentioned in msg 177059 above. New patch 'issue16596_nostate_3.diff' fixes both problems by having the interpreter
|
Forgot to say that the only difference between this patch and the previous one is in Python/ceval.c. |
It's not fixed. Let me paste in a session. This uses the latest Tulip repo (simple_tcp_server.py was just added). I've added "import pdb; pdb.set_trace()" to the top of the client() coroutine, to set a breakpoint (I'm a very unsophisticated pdb user :-). I step over a yield-from, great. Then I step into recv(). Note the final 'n' command. This is at the return statement in recv(). At this point I expect to go back into the client() coroutine, but somehow the debugger loses control and the program finishes execution without giving control back. bash-3.2$ ~/cpython/python.exe -m examples.simple_tcp_server
|
Hopefully issue16596_nostate_4.diff should fix this. |
This version works beautifully in that scenario! Does anyone else reading this bug report object to this being committed? |
New changeset 95eea8624d05 by Guido van Rossum in branch 'default': |
This commit created a reference leak: ./python -m test -R 3:2 test_trace |
It looks like call_exc_trace is leaking refs to Py_None. I believe the attached patch fixes the issue (it certainly fixes Antoine's failing invokation :) |
Full run of the test suite was clean, so the fix is ready to go. |
Yes, actually, 4f730c045f5f is the culprit. |
New changeset 8f556ee0f6ba by Antoine Pitrou in branch 'default': |
I committed a simpler fix. |
New changeset 5c6c96c82afb by R David Murray in branch 'default': |
Documentation update attached. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: