[issue210631] Debugger does not understand packages (PR#283)

Change by admin : ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue210631] Debugger does not understand packages (PR#283)

Change by admin : -- github: None -> 32702 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42548] debugger stops at breakpoint of `pass` that is not actually reached

Irit Katriel added the comment: On second thought I won't keep this open till it expires. This is a low priority bug which no longer exists in new versions because it was fixed by accident due to another change. I don't believe anyone would care enough about this to investigate how it

[issue46908] Debugger jumps to a wrong instruction in for loop

Vedran Čačić added the comment: pdb on Py3.10.2 works fine with that code. -- nosy: +veky ___ Python tracker ___ ___

[issue46908] Debugger jumps to a wrong instruction in for loop

Change by Brandt Bucher : -- nosy: +brandtbucher ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46908] Debugger jumps to a wrong instruction in for loop

Mark Shannon added the comment: Which debugger? Which version of Python? Please provide all the steps required to reproduce, otherwise there is little we can do. -- nosy: +Mark.Shannon ___ Python tracker <https://bugs.python.org/issue46

[issue46908] Debugger jumps to a wrong instruction in for loop

New submission from Francisco Arenas Afán de Rivera : I found that the debugger doesn't follow the normal program order when executing a foor loop with more than 3 instructions inside and one loop. code example: a = 0 b = 0 c = 0 for i in range(1): a += 1 b += 1 # Set breakpoint here

[issue42548] debugger stops at breakpoint of `pass` that is not actually reached

Irit Katriel added the comment: Fine, I’ll reopen it for 3.9. However, realistically the release managers are unlikely to investigate how this bug got fixed between 3.9 and 3.11 so if you think this is important you might want to do that work. -- resolution: out of date -> status:

[issue42548] debugger stops at breakpoint of `pass` that is not actually reached

Andy S added the comment: Then maybe those RMs (for 3.9 and 3.10) should decide on their own? That should mean the bug should be reopened for them to get assigned to. -- ___ Python tracker

[issue42548] debugger stops at breakpoint of `pass` that is not actually reached

Irit Katriel added the comment: It depends how risky the 3.9 release manager would consider the fix to be. The first step would be to find out which commit(s) fixed it. -- ___ Python tracker

[issue42548] debugger stops at breakpoint of `pass` that is not actually reached

Andy S added the comment: Can reproduce this on 3.9. Is the fact 3.9 is in `bugfix` status enough to backport any fixing changes from 3.11 (if that's true and the bug was fixed)? -- ___ Python tracker

[issue42548] debugger stops at breakpoint of `pass` that is not actually reached

Irit Katriel added the comment: I can't reproduce this on 3.11. 3.7 is no longer maintained, and there have been many changes since then to the trace output. It is likely that this bug has been fixed, but please create a new issue if you see it on a current version. -- nosy:

[issue46096] Support PyObject interface for global variables in local scope and debugger

Change by Dmitry : -- keywords: +patch pull_requests: +28359 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30141 ___ Python tracker ___

[issue46096] Support PyObject interface for global variables in local scope and debugger

by PyObject interface. But we faced with an issue: 1) Setting/deleting global variables in local scope are done outside of our control (without using PyObject interface). 2) A debugger (LOAD_NAME tag) does not see global variables in local scope. We would like to fix that issue by adding

[issue41062] Advanced Debugger Support C-API is useless without HEAD_LOCK()/HEAD_UNLOCK()

Change by Irit Katriel : -- type: behavior -> enhancement versions: +Python 3.11 -Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker

[issue45951] Debugger cannot be resolved

Change by Ben : -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker ___ ___ Python-bugs-list

[issue45951] Debugger cannot be resolved

yes, but I didn't change anything or close the program. I left the night before and when I attempted it this morning it started behaving in this manner. -- files: Python error.png messages: 407473 nosy: boett1 priority: normal severity: normal status: open title: Debugger cannot be reso

[issue41062] Advanced Debugger Support C-API is useless without HEAD_LOCK()/HEAD_UNLOCK()

Change by Irit Katriel : -- nosy: +vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36550] Avoid creating AttributeError exceptions in the debugger

Irit Katriel added the comment: Reopened. -- resolution: rejected -> status: closed -> open versions: -Python 3.6, Python 3.7, Python 3.8 ___ Python tracker ___

[issue36550] Avoid creating AttributeError exceptions in the debugger

daniel hahler added the comment: Given code like the following the try/except handling of Pdb (via `Cmd.onecmd`, see https://github.com/python/cpython/pull/4666) will mess with `sys.exc_info()`, which could be avoided: ``` try: raise ValueError() except Exception as exc: e = exc

[issue36550] Avoid creating AttributeError exceptions in the debugger

Irit Katriel added the comment: Closing as the bug is not clear and the OP is not responding to requests on the PR to clarify it. Please create a new issue if you are still seeing a problem. -- nosy: +iritkatriel resolution: -> rejected stage: patch review -> resolved status: open

NoPdb 0.1.0 – Non-interactive Python Debugger

I'm happy to announce the release of NoPdb 0.1.0! NoPdb is a non-interactive (programmatic) debugger for Python. This means it gives you access to debugger-like superpowers directly from your code. NoPdb allows to: - capture function calls, including arguments, local variables, return values

[issue24160] Pdb sometimes raises exception when trying to remove a breakpoint defined in a different debugger session

Pablo Galindo Salgado added the comment: PR 25182 fixes the issue, so I am closing this again. Thanks for the quick fix, Irit! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue24160] Pdb sometimes raises exception when trying to remove a breakpoint defined in a different debugger session

Pablo Galindo Salgado added the comment: New changeset aadd4e10fda87b64ea527667238503da326a06e7 by Irit Katriel in branch 'master': bpo-24160: Fix test_pdb refleaks failure (GH-25182) https://github.com/python/cpython/commit/aadd4e10fda87b64ea527667238503da326a06e7 --

[issue24160] Pdb sometimes raises exception when trying to remove a breakpoint defined in a different debugger session

Irit Katriel added the comment: With the patch: PS C:\Users\User\src\cpython-dev> ./python -m test test_pdb -R 3:3 Running Debug|x64 interpreter... 0:00:00 Run tests sequentially 0:00:00 [1/1] test_pdb beginning 6 repetitions 123456 .. == Tests result: SUCCESS == 1 test OK. Total

[issue24160] Pdb sometimes raises exception when trying to remove a breakpoint defined in a different debugger session

Change by Irit Katriel : -- pull_requests: +23924 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/25182 ___ Python tracker ___

[issue24160] Pdb sometimes raises exception when trying to remove a breakpoint defined in a different debugger session

Irit Katriel added the comment: Thanks, I'm looking. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24160] Pdb sometimes raises exception when trying to remove a breakpoint defined in a different debugger session

Pablo Galindo Salgado added the comment: Per our buildbot policy (https://discuss.python.org/t/policy-to-revert-commits-on-buildbot-failure/404) we will need to revert this in 24 hours if is not fixed to avoid masking future errors. -- ___

[issue24160] Pdb sometimes raises exception when trying to remove a breakpoint defined in a different debugger session

Pablo Galindo Salgado added the comment: Unfortunately PR21989 has breaking the refleaks buildbots. Example: https://buildbot.python.org/all/#/builders/320/builds/226/steps/5/logs/stdio To reproduce: ❯ ./python -m test test_pdb -R 3:3 0:00:00 load avg: 1.40 Run tests sequentially 0:00:00

[issue24160] Pdb sometimes raises exception when trying to remove a breakpoint defined in a different debugger session

Irit Katriel added the comment: Thanks! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue24160] Pdb sometimes raises exception when trying to remove a breakpoint defined in a different debugger session

Guido van Rossum added the comment: New changeset ad442a674ca443feec43a88a2d3671784712e550 by Irit Katriel in branch 'master': bpo-24160: Fix breakpoints persistence across multiple pdb sessions (GH-21989) https://github.com/python/cpython/commit/ad442a674ca443feec43a88a2d3671784712e550

[issue33065] IDLE debugger: failure stepping through module loading

Change by Terry J. Reedy : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue33065] IDLE debugger: failure stepping through module loading

miss-islington added the comment: New changeset 799f8489d418b7f9207d333eac38214931bd7dcc by Miss Islington (bot) in branch '3.9': bpo-33065: Fix problem debugging user classes with __repr__ method (GH-24183) https://github.com/python/cpython/commit/799f8489d418b7f9207d333eac38214931bd7dcc

[issue33065] IDLE debugger: failure stepping through module loading

miss-islington added the comment: New changeset 5ded7efa6a7a232dd4a41e6e65e4dae47146514b by Miss Islington (bot) in branch '3.8': bpo-33065: Fix problem debugging user classes with __repr__ method (GH-24183) https://github.com/python/cpython/commit/5ded7efa6a7a232dd4a41e6e65e4dae47146514b

[issue33065] IDLE debugger: failure stepping through module loading

Change by miss-islington : -- pull_requests: +23013 pull_request: https://github.com/python/cpython/pull/24185 ___ Python tracker ___

[issue33065] IDLE debugger: failure stepping through module loading

Change by miss-islington : -- nosy: +miss-islington nosy_count: 5.0 -> 6.0 pull_requests: +23012 stage: commit review -> patch review pull_request: https://github.com/python/cpython/pull/24184 ___ Python tracker

[issue33065] IDLE debugger: failure stepping through module loading

Terry J. Reedy added the comment: New changeset 81f87bbf9f65702062021a78abd9b8f82c98a414 by Terry Jan Reedy in branch 'master': bpo-33065: Fix problem debugging user classes with __repr__ method (GH-24183) https://github.com/python/cpython/commit/81f87bbf9f65702062021a78abd9b8f82c98a414

[issue33065] IDLE debugger: failure stepping through module loading

Terry J. Reedy added the comment: I am reluctant to make changes without adding tests, and until I focused again on how to do so, because of your ping, I had no idea how to do so. The added test results in the same error, "AttributeError: 'BinData' object has no attribute 'length'" without

[issue33065] IDLE debugger: failure stepping through module loading

Change by Terry J. Reedy : -- keywords: +patch pull_requests: +23011 stage: test needed -> patch review pull_request: https://github.com/python/cpython/pull/24183 ___ Python tracker

[issue33065] IDLE debugger: failure stepping through module loading

Timothy Geiser added the comment: This issue is still open, 8.5 months after identifying the underlying cause. What needs done to get a fix for this merged? Manual testing, or adding test cases? Anything I can do to help? I have 3.9.1 successfully built on a Raspberry Pi that I can reproduce

[issue14111] IDLE Debugger should handle interrupts

Mark Roseman added the comment: Terry, I agree that Ctrl-C should act just as an interrupt when the debugger is active. I also agree that a way to interrupt the debugger through the user interface is needed (in the revised UI, there's an explicit 'stop' button

[issue42548] debugger stops at breakpoint of `pass` that is not actually reached

mal severity: normal status: open title: debugger stops at breakpoint of `pass` that is not actually reached type: behavior versions: Python 3.7 Added file: https://bugs.python.org/file49649/debug_bug.py ___ Python tracker &l

[issue14111] IDLE Debugger should handle interrupts

Terry J. Reedy added the comment: Mark, since you are working on redoing the debugger gui, do you have any opinion on this? The basic idea is that ^C when debugging should just interrupt the remote process, not end it, just as when there is no debugger. I agree. I just updated the PR

[issue24160] Pdb sometimes raises exception when trying to remove a breakpoint defined in a different debugger session

Tal Einat added the comment: Irit, I like the approach of your PR for an immediate fix, that we could consider backporting. In the long term, ISTM that we should refactor to store the breakpoints with only a single source of truth, and avoid the duplication between Breakpoint.bplist,

[issue17942] IDLE Debugger: Improve GUI

Change by Mark Roseman : -- versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.6, Python 3.7 ___ Python tracker ___ ___

[issue17942] IDLE Debugger: Improve GUI

Mark Roseman added the comment: have updated/cleaned up the previous patch, and there's a new PR. i realize this is unfortunately a somewhat monolithic change which might make reviewing it a bit tough... -- ___ Python tracker

[issue17942] IDLE Debugger: Improve GUI

Change by Mark Roseman : -- pull_requests: +21864 pull_request: https://github.com/python/cpython/pull/22947 ___ Python tracker ___

[issue14979] pdb doc: Explain how to extend debugger instead of sending readers to the source

Change by Irit Katriel : -- type: -> enhancement versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker

[issue20119] pdb c(ont(inue)) optional one-time-only breakpoint (like perl debugger)

Change by Irit Katriel : -- resolution: -> out of date stage: test needed -> resolved status: open -> closed ___ Python tracker ___

[issue20119] pdb c(ont(inue)) optional one-time-only breakpoint (like perl debugger)

Change by Georg Brandl : -- nosy: -georg.brandl ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24160] Pdb sometimes raises exception when trying to remove a breakpoint defined in a different debugger session

Change by Georg Brandl : -- nosy: -georg.brandl ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24160] Pdb sometimes raises exception when trying to remove a breakpoint defined in a different debugger session

Change by Irit Katriel : -- title: Pdb sometimes crashes when trying to remove a breakpoint defined in a different debugger sessoon -> Pdb sometimes raises exception when trying to remove a breakpoint defined in a different debugger session versions: +Python 3.10 -Python 2.7, Pyt

[issue20119] pdb c(ont(inue)) optional one-time-only breakpoint (like perl debugger)

Irit Katriel added the comment: Pdb already has this, it's the tbreak command. -- nosy: +iritkatriel ___ Python tracker ___ ___

[issue24160] Pdb sometimes crashes when trying to remove a breakpoint defined in a different debugger sessoon

Irit Katriel added the comment: I've submitted a patch that I believe fixes this problem. It adds in Bdb's __init__ a call to a function that reads the Breakpoint's 'bplist' and 'bpbynumber' class attributes and populates the new instances' 'breaks' dict. --

[issue24160] Pdb sometimes crashes when trying to remove a breakpoint defined in a different debugger sessoon

Change by Irit Katriel : -- keywords: +patch nosy: +iritkatriel nosy_count: 4.0 -> 5.0 pull_requests: +21098 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21989 ___ Python tracker

[issue41062] Advanced Debugger Support C-API is useless without HEAD_LOCK()/HEAD_UNLOCK()

Andrei Pashkin added the comment: Here is what I mean by "Advanced Debugger Support" API: https://docs.python.org/dev/c-api/init.html#advanced-debugger-support -- ___ Python tracker <https://bugs.python.o

[issue41062] Advanced Debugger Support C-API is useless without HEAD_LOCK()/HEAD_UNLOCK()

New submission from Andrei Pashkin : To me it seems like Advanced Debugger Support C-API doesn't make sense without HEAD_LOCK() and HEAD_UNLOCK() which are private right now. When researching how C-API works I've found this comment in the source code: https://github.com/python/cpython/blob

[issue24996] IDLE: debugger local/global vars should not be editable

Change by Terry J. Reedy : -- versions: +Python 3.10 -Python 3.6, Python 3.7 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue25146] IDLE debugger could better visualize program execution

Change by Terry J. Reedy : -- versions: +Python 3.10 -Python 3.5, Python 3.6 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue24826] ability to integrate editor, shell, debugger in one window

Change by Terry J. Reedy : -- versions: +Python 3.10 -Python 3.5, Python 3.6 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue40403] pdb does not drop into debugger upon SyntaxError caused by ast.literal_eval

Xavier de Gaye added the comment: > Perhaps we should should test whether the exception happened there and not > drop in the debugger in that case? The same kind of problem occurs for any post-mortem debugging raised by an uncaught exception in the user code: the backtrace dis

[issue40403] pdb does not drop into debugger upon SyntaxError caused by ast.literal_eval

Change by Batuhan Taskaya : -- nosy: +BTaskaya ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40403] pdb does not drop into debugger upon SyntaxError caused by ast.literal_eval

Rémi Lapeyre added the comment: Yes, the patch by Terry Reedy fixes this issue while still breaking the loop from `def f: pass`. It will start the debugger once for `def f: pass` which may be weird as in this case no user code has been executed and it will be in bdb which may confuse users

[issue40403] pdb does not drop into debugger upon SyntaxError caused by ast.literal_eval

Xavier de Gaye added the comment: In Kerrick's example ast.literal_eval('') could be ast.literal_eval(some_code) instead where some_code is a string containing dynamically generated Python code. pdb post-mortem debugging must allow finding the syntax error in this code. The patch proposed

[issue40403] pdb does not drop into debugger upon SyntaxError caused by ast.literal_eval

Rémi Lapeyre added the comment: This is related to issue 16180, it may be possible to improve the situation by trying to determine whether the SyntaxError is in the file or came during its execution by looking at the filename but it's probably very brittle: # In most cases

[issue40403] pdb does not drop into debugger upon SyntaxError caused by ast.literal_eval

Rémi Lapeyre added the comment: I've looked into this, in Bdb both the part where the code is compiled and the one where the code is run are in the run() method (https://github.com/python/cpython/blob/master/Lib/bdb.py#L565-L585): def run(self, cmd, globals=None, locals=None):

[issue33065] IDLE debugger: failure stepping through module loading

Terry J. Reedy added the comment: SO duplicate. https://stackoverflow.com/questions/61310989/python-idle-importing-xlrd-error-generated-in-debug-mode-attributeerror-mo -- ___ Python tracker

[issue40403] pdb does not drop into debugger upon SyntaxError caused by ast.literal_eval

is displayed. System configuration: Python 3.8.2 on Arch Linux. -- components: Library (Lib) messages: 367363 nosy: Kerrick Staley priority: normal severity: normal status: open title: pdb does not drop into debugger upon SyntaxError caused by ast.literal_eval type: behavior versions: Python 3.8

[issue33065] IDLE debugger: failure stepping through module loading

Timothy Geiser added the comment: Looks good when testing both the minimal example and the pgpdump original case. I added the import at the top, and changed the original line 173 from value = repr(value) to value = reprlib.repr(value) This is based on lines 160 & 161 in reprlib (we need a

[issue33065] IDLE debugger: failure stepping through module loading

Change by ppperry : -- nosy: -ppperry ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33065] IDLE debugger: failure stepping through module loading

Terry J. Reedy added the comment: Timothy, can you try editing idlelib.debugger_r, line 173, as suggested above and see if it solves the problem? -- ___ Python tracker ___

[issue33065] IDLE debugger: failure stepping through module loading

Terry J. Reedy added the comment: I believe I found the bug. For IDLE's original single process mode, still available with the -n startup option, debugger.py contains the entire debugger. The values displayed for global and local names are obtained with reprlib.Repr.repr. That in turn

[issue33065] IDLE debugger: failure stepping through module loading

Timothy Geiser added the comment: It looks like the IDLE debugger seems to call repr on objects to present in the Locals list, even before they've been properly initialized. If __repr__ needs to refer to variables that don't exist until __init__ is done (and I don't think it's unreasonable

[issue33065] IDLE debugger: failure stepping through module loading

Terry J. Reedy added the comment: Timothy, this is already more helpful than a simple 'me too'. Can you reduce pgdata.dump to a truly minimal file that exhibits the bug? and then upload it? Installing any package into my local copy of the master CPython repository is problemmatical.

[issue33065] IDLE debugger: failure stepping through module loading

from pip) on Windows 10 and wanted to step through how it worked. As soon as I enabled the debugger in IDLE it stopped working, throwing a very similar stack trace. Here's the MWE: >>> import pgpdump >>> [DEBUG ON] >>> pgpdump.BinaryData(b'') Traceback (most

[issue24816] IDLE: disable selecting debugger when user code is running

Change by Terry J. Reedy : -- assignee: -> terry.reedy stage: -> needs patch title: don't allow selecting IDLE debugger menu item when running -> IDLE: disable selecting debugger when user code is running versions: +Python 3.9 -Python 2.7, Python 3.5, P

[issue24818] IDLE: run program in debugger from edit window

Change by Terry J. Reedy : -- assignee: -> terry.reedy nosy: -kbk, roger.serwy title: no way to run program in debugger from edit window -> IDLE: run program in debugger from edit window versions: +Python 3.9 -Python 2.7, Python 3.5, Pyth

Awaiting coroutines inside the debugger (PDB)

. But this does not seem to work when in PDB (and consequently in iPDB) when running `import pdb; pdb.set_trace()`. Is there any workaround to get `await` working in PDB, or any simple way to synchronously wait while in the debugger? -- https://mail.python.org/mailman/listinfo/python-list

[issue15348] IDLE - shell becomes unresponsive if debugger windows is closed while active.

Terry J. Reedy added the comment: The input glitch mentioned above no longer exists, so closing. -- resolution: -> fixed stage: needs patch -> resolved status: open -> closed ___ Python tracker

[issue15347] IDLE - remove debugger 'interacting'

Terry J. Reedy added the comment: fix-nested-mainloop.patch was superceded by fix-nested2.patch for #24455. I verified that the initial test now passes. When I click 'yes' in that box popped up by step 4, both Shell and debugger windows disappear and IDLE exists. The only question left

[issue33882] doc Mention breakpoint() in debugger-related FAQ

Stéphane Wirtel added the comment: Thank you for your PR, -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue33882] doc Mention breakpoint() in debugger-related FAQ

Stéphane Wirtel added the comment: New changeset af5ef3e1077bc2ed177a7c8598f8ecc756ecf6f9 by Stéphane Wirtel (Miss Islington (bot)) in branch '3.7': bpo-33882: mention breakpoint() in debugger-related FAQ (GH-7759) (GH-13077) https://github.com/python/cpython/commit

[issue33882] doc Mention breakpoint() in debugger-related FAQ

Change by miss-islington : -- pull_requests: +12991 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33882] doc Mention breakpoint() in debugger-related FAQ

Éric Araujo added the comment: New changeset cf48e55f7f7718482fa712552f0cbc0aea1c826f by Éric Araujo (Andre Delfino) in branch 'master': bpo-33882: mention breakpoint() in debugger-related FAQ (GH-7759) https://github.com/python/cpython/commit/cf48e55f7f7718482fa712552f0cbc0aea1c826f

[issue36550] Avoid creating AttributeError exceptions in the debugger

) messages: 339583 nosy: blueyed priority: normal severity: normal status: open title: Avoid creating AttributeError exceptions in the debugger versions: Python 3.9 ___ Python tracker <https://bugs.python.o

[issue36550] Avoid creating AttributeError exceptions in the debugger

Change by daniel hahler : -- keywords: +patch pull_requests: +12643 stage: -> patch review ___ Python tracker ___ ___

[issue15347] IDLE - does not close if the debugger was active

Change by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24090] Add a "copy value to clipboard" option to the debugger

itor does not wrap). Pasting into command prompt is not good either. Notepad++ handles the 6 char line pretty well. I am not sure what I was thinking about a block copy in Shell. If a block is selected, it is easily copied. My thinking now is that large output in the debugger should be

[issue33065] IDLE debugger: failure stepping through module loading

Terry J. Reedy added the comment: A StackOverflow use got the same _ModuleLock message. https://stackoverflow.com/questions/54785596/debugger-in-python-freezes-over-own-built-modules -- ___ Python tracker <https://bugs.python.org/issue33

[issue35690] IDLE: Fix and test debugger.

Change by anthony shaw : -- keywords: +patch pull_requests: +10971 stage: needs patch -> patch review ___ Python tracker ___ ___

[issue35690] IDLE: Fix and test debugger.

New submission from Terry J. Reedy : Move PR 11451 from #35668. * Remove use of blank comments to make blank lines. * Greatly expand test_debugger. * Fix a couple of issues discovered while writing tests. (It is possible that one of these caused one of the reported debugger bugs, but we don't

[issue35690] IDLE: Fix and test debugger.

Change by Terry J. Reedy : -- assignee: -> terry.reedy components: +IDLE ___ Python tracker ___ ___ Python-bugs-list mailing list

ANN: elicit CLI framework with enhanced debugger 1.7

the chained exceptions. So I've recently added that feature to my debugger module. It's contained in the Elicit package. https://pypi.org/project/elicit/ The new commands "switch", and "cause" will switch tracebacks to the "context", or "cause" exceptio

[issue33065] IDLE debugger: failure stepping through module loading

Change by Terry J. Reedy : -- versions: -Python 3.6 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34870] Core dump when Python VSCode debugger is attached

Change by Terry J. Reedy : -- resolution: -> third party stage: -> resolved status: open -> closed type: -> behavior ___ Python tracker ___

[issue34870] Core dump when Python VSCode debugger is attached

Steve Dower added the comment: Perhaps surprisingly, Brett is :) This is best reported at https://github.com/Microsoft/ptvsd, so I'd suggest just taking it over there. If it turns out to be a Python issue, we'll bring it back. -- nosy: +brett.cannon

[issue34870] Core dump when Python VSCode debugger is attached

Terry J. Reedy added the comment: Steve, are you responsible for VSCode and Python? -- nosy: +steve.dower, terry.reedy ___ Python tracker ___

[issue34870] Core dump when Python VSCode debugger is attached

Change by Karthikeyan Singaravelan : -- nosy: +xtreak ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34870] Core dump when Python VSCode debugger is attached

New submission from Per Lundberg : My code has recently started triggering a core dump in the Python executable when the VSCode debugger is attached. This doesn't happen right away; it seems to happen more or less _after_ the program is done executing (I just placed a breakpoint and stepped

[issue33065] IDLE debugger: failure stepping through module loading

ppperry added the comment: Line 59 isn't actually executed; the error comes from the trace event that gets fired before line 59, which is the first `line` event in the frame containing the uninitialized _ModuleLock. -- nosy: +ppperry ___ Python

  1   2   3   4   5   >