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

[admin]

Change by admin :


___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[admin]

Change by admin :


--
github: None -> 32702

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

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 accidentally got fixed (and then 
investigate how it can be fixed in 3.9).

In my judgement it's not worth anyone (core devs or contributors) spending any 
more time on this (even just reading it and moving on). We have over 7000 open 
issues and only a handful of volunteers reviewing and fixing them.

I found msg412785 a bit rude, but I will give you the benefit of the doubt that 
you didn't intend for it to come across that way. If you still believe that I 
am overstepping my authority and this should be decided by the RMs, I suggest 
you raise this with the SC or on python-dev.

--
resolution:  -> out of date
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Vedran Čačić]

Vedran Čačić  added the comment:

pdb on Py3.10.2 works fine with that code.

--
nosy: +veky

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Brandt Bucher]

Change by Brandt Bucher :


--
nosy: +brandtbucher

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Shannon]

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/issue46908>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Francisco Arenas Afán de Rivera]

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
c += 1 # Also crash with breakpoint here

jumps to the line b += 1 after the end of the loop and crashes with error: 
Process finished with exit code -1073741819 (0xC005)

--
messages: 414417
nosy: franarenasafan
priority: normal
severity: normal
status: open
title: Debugger jumps to a wrong instruction in for loop
versions: Python 3.10

___
Python tracker 
<https://bugs.python.org/issue46908>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

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: closed -> open
versions: +Python 3.9 -Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Andy S]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Andy S]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

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: +iritkatriel
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Dmitry]

Change by Dmitry :


--
keywords: +patch
pull_requests: +28359
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/30141

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Dmitry]

New submission from Dmitry :

We use the embedded Python in a multiscript environment. For example, VBS can 
execute Python code and vice versa. 

For that purpose we use a global context which is common for all running 
scripts (Python, VBS etc.) and control access to variables in that context 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 a check for exact PyDict 
(PyDict_CheckExact) in STORE_GLOBAL, DELETE_GLOBAL and LOAD_NAME tags in 
ceval.c. 
If a global dictionary is redefined then use PyObject interface instead of 
direct PyDict one.

--
components: Interpreter Core
hgrepos: 412
messages: 408684
nosy: dzhamoytsin
priority: normal
severity: normal
status: open
title: Support PyObject interface for global variables in local scope and 
debugger
type: behavior
versions: Python 3.9

___
Python tracker 
<https://bugs.python.org/issue46096>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45951] Debugger cannot be resolved

[Ben]

Change by Ben :


--
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45951] Debugger cannot be resolved

[Ben]

New submission from Ben :

First, I am not a programmer by any stretch of the imagination, and I am just 
trying to get this error solved.

I attempted to highlight and comment out a section of code, maybe 20 lines, and 
the program froze, greyed out, and gave me a spinning wheel mouse.

I closed & reopened program, attempted with one line of code and it worked, 
attempted again with 5 lines and same issue occurred.

I have attached a screenshot of the error message and didn't seen how the 
associated error related.  

https://bugs.python.org/issue1180193

The screen was greyed out 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 resolved
versions: Python 3.7
Added file: https://bugs.python.org/file50468/Python error.png

___
Python tracker 
<https://bugs.python.org/issue45951>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

Change by Irit Katriel :


--
nosy: +vstinner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36550] Avoid creating AttributeError exceptions in the debugger

[Irit Katriel]

Irit Katriel  added the comment:

Reopened.

--
resolution: rejected -> 
status: closed -> open
versions:  -Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36550] Avoid creating AttributeError exceptions in the debugger

[daniel hahler]

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
__import__('pdb').set_trace()
```

```
% ./python t_issue36550.py
--Return--
> …/t_issue36550.py(5)()->None
-> __import__('pdb').set_trace()
(Pdb) import sys; sys.exc_info()
(, AttributeError("'Pdb' object has no attribute 
'do_import'"), )
```

The initial / better motivation was described in the original issue: with 
pdb++/pdbpp I want to display tracebacks/errors with errors that might occur 
via Pdb's prompt, where this then showed up as interfering with it.

(Sorry for not responding on https://github.com/python/cpython/pull/4666 
earlier, but I think it is only part of this issue, and therefore it should not 
get closed, and also creating a new one instead does not sound useful to me, so 
please consider to re-open it instead.)

--
versions: +Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36550] Avoid creating AttributeError exceptions in the debugger

[Irit Katriel]

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 -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

NoPdb 0.1.0 – Non-interactive Python Debugger

[Ondřej Cífka]

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 
and stack traces
- set "breakpoints" that trigger user-defined actions when hit, namely:
- evaluate expressions to retrieve their values later
- execute arbitrary code, including modifying local variables
- enter an interactive debugger like pdb

Installation: pip install nopdb
Docs: https://nopdb.readthedocs.io/
GitHub: https://github.com/cifkao/nopdb
License: BSD-3-Clause


https://github.com/cifkao/nopdb;>NoPdb 0.1.0,
a non-interactive Python debugger. (06-Apr-21)
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

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

[Pablo Galindo Salgado]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Pablo Galindo Salgado]

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


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

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 duration: 34.2 sec
Tests result: SUCCESS

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

Change by Irit Katriel :


--
pull_requests: +23924
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/25182

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

Irit Katriel  added the comment:

Thanks, I'm looking.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Pablo Galindo Salgado]

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Pablo Galindo Salgado]

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 load avg: 1.40 [1/1] test_pdb
beginning 6 repetitions
123456
.test test_pdb failed -- Traceback (most recent call last):
  File "/home/pablogsal/github/cpython/Lib/doctest.py", line 2205, in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for 
test.test_pdb.test_pdb_breakpoints_preserved_across_interactive_sessions
  File "/home/pablogsal/github/cpython/Lib/test/test_pdb.py", line 326, in 
test_pdb_breakpoints_preserved_across_interactive_sessions

--
File "/home/pablogsal/github/cpython/Lib/test/test_pdb.py", line 330, in 
test.test_pdb.test_pdb_breakpoints_preserved_across_interactive_sessions
Failed example:
with PdbTestInput([  # doctest: +ELLIPSIS, +NORMALIZE_WHITESPACE
   'import test.test_pdb',
   'break test.test_pdb.do_something',
   'break test.test_pdb.do_nothing',
   'break',
   'continue',
]):
   pdb.run('print()')
Expected:
> (1)()
(Pdb) import test.test_pdb
(Pdb) break test.test_pdb.do_something
Breakpoint 1 at ...test_pdb.py:...
(Pdb) break test.test_pdb.do_nothing
Breakpoint 2 at ...test_pdb.py:...
(Pdb) break
Num Type Disp Enb   Where
1   breakpoint   keep yes   at ...test_pdb.py:...
2   breakpoint   keep yes   at ...test_pdb.py:...
(Pdb) continue
Got:
> (1)()->None
(Pdb) import test.test_pdb
(Pdb) break test.test_pdb.do_something
Breakpoint 1 at /home/pablogsal/github/cpython/Lib/test/test_pdb.py:396
(Pdb) break test.test_pdb.do_nothing
Breakpoint 2 at /home/pablogsal/github/cpython/Lib/test/test_pdb.py:393
(Pdb) break
Num Type Disp Enb   Where
1   breakpoint   keep yes   at 
/home/pablogsal/github/cpython/Lib/test/test_pdb.py:396
2   breakpoint   keep yes   at 
/home/pablogsal/github/cpython/Lib/test/test_pdb.py:393
(Pdb) continue

--
File "/home/pablogsal/github/cpython/Lib/test/test_pdb.py", line 350, in 
test.test_pdb.test_pdb_breakpoints_preserved_across_interactive_sessions
Failed example:
with PdbTestInput([  # doctest: +ELLIPSIS, +NORMALIZE_WHITESPACE
   'break',
   'break pdb.find_function',
   'break',
   'clear 1',
   'continue',
]):
   pdb.run('print()')
Expected:
> (1)()
(Pdb) break
Num Type Disp Enb   Where
2   breakpoint   keep yes   at ...test_pdb.py:...
3   breakpoint   keep yes   at ...pdb.py:...
(Pdb) clear 2
Deleted breakpoint 2 at ...test_pdb.py:...
(Pdb) clear 3
Deleted breakpoint 3 at ...pdb.py:...
(Pdb) continue
Got:
> (1)()->None
(Pdb) break
Num Type Disp Enb   Where
2   breakpoint   keep yes   at 
/home/pablogsal/github/cpython/Lib/test/test_pdb.py:393
3   breakpoint   keep yes   at /home/pablogsal/github/cpython/Lib/pdb.py:94
(Pdb) clear 2
Deleted breakpoint 2 at 
/home/pablogsal/github/cpython/Lib/test/test_pdb.py:393
(Pdb) clear 3
Deleted breakpoint 3 at /home/pablogsal/github/cpython/Lib/pdb.py:94
(Pdb) continue



test_pdb failed

== Tests result: FAILURE ==

1 test failed:
test_pdb

Total duration: 2.8 sec
Tests result: FAILURE

--
nosy: +pablogsal
resolution: fixed -> 
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

Irit Katriel  added the comment:

Thanks!

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Guido van Rossum]

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


--
nosy: +gvanrossum

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33065] IDLE debugger: failure stepping through module loading

[Terry J. Reedy]

Change by Terry J. Reedy :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33065] IDLE debugger: failure stepping through module loading

[miss-islington]

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


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33065] IDLE debugger: failure stepping through module loading

[miss-islington]

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


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33065] IDLE debugger: failure stepping through module loading

[miss-islington]

Change by miss-islington :


--
pull_requests: +23013
pull_request: https://github.com/python/cpython/pull/24185

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33065] IDLE debugger: failure stepping through module loading

[miss-islington]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33065] IDLE debugger: failure stepping through module loading

[Terry J. Reedy]

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


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33065] IDLE debugger: failure stepping through module loading

[Terry J. Reedy]

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 the patch and passes with it.

--
stage: patch review -> commit review
versions: +Python 3.10 -Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33065] IDLE debugger: failure stepping through module loading

[Terry J. Reedy]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33065] IDLE debugger: failure stepping through module loading

[Timothy Geiser]

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 the issue on, as well as reproduce the fix 
Terry suggested in msg366981.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14111] IDLE Debugger should handle interrupts

[Mark Roseman]

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 for 
that).

--

___
Python tracker 
<https://bugs.python.org/issue14111>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Andy S]

New submission from Andy S :

The python (3.6) doc states 
(https://docs.python.org/3/reference/simple_stmts.html#the-pass-statement):

pass is a null operation...

So since this is still an operation one could expect that it can be used as an 
op to breakpoint on while debugging some scripts.

Nevertheless:

$ pdb3.7 ./debug_bug.py 
> /...play/debug_bug.py(1)()
-> a = None
(Pdb) list
  1  -> a = None
  2  
  3  
  4 def fun():
  5 b = False
  6 if a is None:
  7 b = True
  8 pass
  9 else:
 10 pass
 11  
(Pdb) 
 12  
 13 fun()
 14 pass
[EOF]
(Pdb) b 10
Breakpoint 1 at /...play/debug_bug.py:10
(Pdb) run
Restarting ./debug_bug.py with arguments:
./debug_bug.py
> /...play/debug_bug.py(1)()
-> a = None
(Pdb) continue
> /...play/debug_bug.py(10)fun()
-> pass
(Pdb) bt
  /usr/lib/python3.7/bdb.py(585)run()
-> exec(cmd, globals, locals)
  (1)()
  /...play/debug_bug.py(13)()
-> fun()
> /...play/debug_bug.py(10)fun()
-> pass
(Pdb) p b
True
(Pdb)

--
components: Interpreter Core, Library (Lib)
files: debug_bug.py
messages: 382351
nosy: gatekeeper.mail
priority: normal
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 
<https://bugs.python.org/issue42548>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14111] IDLE Debugger should handle interrupts

[Terry J. Reedy]

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 to current master but have not at the moment tested it.

--
nosy:  -roger.serwy
versions: +Python 3.10 -Python 3.7

___
Python tracker 
<https://bugs.python.org/issue14111>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Tal Einat]

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, Breakpoint.bpbynumber and Bdb.breaks.

--
nosy: +taleinat

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17942] IDLE Debugger: Improve GUI

[Mark Roseman]

Change by Mark Roseman :


--
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.6, Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17942] IDLE Debugger: Improve GUI

[Mark Roseman]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17942] IDLE Debugger: Improve GUI

[Mark Roseman]

Change by Mark Roseman :


--
pull_requests: +21864
pull_request: https://github.com/python/cpython/pull/22947

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

Change by Irit Katriel :


--
resolution:  -> out of date
stage: test needed -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Georg Brandl]

Change by Georg Brandl :


--
nosy:  -georg.brandl

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Georg Brandl]

Change by Georg Brandl :


--
nosy:  -georg.brandl

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

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, Python 3.5

___
Python tracker 
<https://bugs.python.org/issue24160>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

Irit Katriel  added the comment:

Pdb already has this, it's the tbreak command.

--
nosy: +iritkatriel

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Andrei Pashkin]

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.org/issue41062>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Andrei Pashkin]

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/e838a9324c1719bb917ca81ede8d766b5cb551f4/Python/pystate.c#L1176

It says that the lists of interpreter-state and thread-state objects (that Adv. 
Debugger Support API operates on) could be mutated even when GIL is held so 
there is need to acquire head mutex when accessing them. But there is no way to 
acquire head mutex using public C-API.

Am I right? If yes - it seems like HEAD_(UN)LOCK() should be made public.

--
components: C API
messages: 371988
nosy: pashkin
priority: normal
severity: normal
status: open
title: Advanced Debugger Support C-API is useless without 
HEAD_LOCK()/HEAD_UNLOCK()
type: behavior
versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 
3.9

___
Python tracker 
<https://bugs.python.org/issue41062>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Terry J. Reedy]

Change by Terry J. Reedy :


--
versions: +Python 3.10 -Python 3.6, Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25146] IDLE debugger could better visualize program execution

[Terry J. Reedy]

Change by Terry J. Reedy :


--
versions: +Python 3.10 -Python 3.5, Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Terry J. Reedy]

Change by Terry J. Reedy :


--
versions: +Python 3.10 -Python 3.5, Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Xavier de Gaye]

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 displayed by the 'bt' 
command shows frames that are owned by the pdb and bdb modules; and worse, the 
'up' command allows to move to these frames. See for example below what happens 
when debugging foo.py that contains only the line "1/0". IMO this problem 
should be handled in another issue and in that case, in your example, 'bt' 
output would be empty.


$ python -m pdb foo.py
> /tmp/foo.py(1)()
-> 1/0
(Pdb) c
Traceback (most recent call last):
  File "/usr/lib/python3.8/pdb.py", line 1703, in main
pdb._runscript(mainpyfile)
  File "/usr/lib/python3.8/pdb.py", line 1572, in _runscript
self.run(statement)
  File "/usr/lib/python3.8/bdb.py", line 580, in run
exec(cmd, globals, locals)
  File "", line 1, in 
  File "/tmp/foo.py", line 1, in 
1/0
ZeroDivisionError: division by zero
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
> /tmp/foo.py(1)()
-> 1/0
(Pdb) bt
  /usr/lib/python3.8/pdb.py(1703)main()
-> pdb._runscript(mainpyfile)
  /usr/lib/python3.8/pdb.py(1572)_runscript()
-> self.run(statement)
  /usr/lib/python3.8/bdb.py(580)run()
-> exec(cmd, globals, locals)
  (1)()
> /tmp/foo.py(1)()
-> 1/0
(Pdb)

--

___
Python tracker 
<https://bugs.python.org/issue40403>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Batuhan Taskaya]

Change by Batuhan Taskaya :


--
nosy: +BTaskaya

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Rémi Lapeyre]

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:


Traceback (most recent call last):
  File "/Users/remi/src/cpython/Lib/pdb.py", line 1703, in main
pdb._runscript(mainpyfile)
  File "/Users/remi/src/cpython/Lib/pdb.py", line 1572, in _runscript
self.run(statement)
  File "/Users/remi/src/cpython/Lib/bdb.py", line 580, in run
exec(cmd, globals, locals)
  File "", line 1, in 
  File "/Users/remi/src/cpython/tests.py", line 1
def f: pass
 ^
SyntaxError: invalid syntax
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
> (1)()
(Pdb) bt
  /Users/remi/src/cpython/Lib/pdb.py(1703)main()
-> pdb._runscript(mainpyfile)
  /Users/remi/src/cpython/Lib/pdb.py(1572)_runscript()
-> self.run(statement)
  /Users/remi/src/cpython/Lib/bdb.py(580)run()
-> exec(cmd, globals, locals)
> (1)()


Perhaps we should should test whether the exception happened there and not drop 
in the debugger in that case?

--

___
Python tracker 
<https://bugs.python.org/issue40403>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Xavier de Gaye]

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 in issue 16180 by Terry may fix this problem (and 
issue 16180).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Rémi Lapeyre]

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 SystemExit does not warrant a post-mortem session.
 print("The program exited via sys.exit(). Exit status:", end=' ')
 print(sys.exc_info()[1])
-except SyntaxError:
-traceback.print_exc()
-sys.exit(1)
-except:
+except Exception as e:
+if (type(e) is SyntaxError and
+e.filename == os.path.abspath(mainpyfile)):
+traceback.print_exc()
+sys.exit(1)
 traceback.print_exc()
 print("Uncaught exception. Entering post mortem debugging")
 print("Running 'cont' or 'step' will restart the program")

--
nosy: +terry.reedy, xdegaye

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Rémi Lapeyre]

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):
"""Debug a statement executed via the exec() function.
globals defaults to __main__.dict; locals defaults to globals.
"""
if globals is None:
import __main__
globals = __main__.__dict__
if locals is None:
locals = globals
self.reset()
if isinstance(cmd, str):
cmd = compile(cmd, "", "exec")
sys.settrace(self.trace_dispatch)
try:
exec(cmd, globals, locals)
except BdbQuit:
pass
finally:
self.quitting = True
sys.settrace(None)


This is an issue as SyntaxError may come from two lines

 - the call to compile() which means the code being run is not valid Python, in 
this case the current behaviour of PDB to exit is correct as there is nothing 
to debug
 - the call to exec() in which case a SyntaxError can happen like in the 
report, and PDB should go in post mortem debug mode.


One way to fix the issue would be to catch the error in compile() and wrap it 
in a BdbSyntaxError so that PDB can differentiate between the two, another to 
keep BDB as it is and change PDB so that it compiles the code first, and call 
run() in a second step. I think the last one is better and will start writing a 
PR for this.

--
nosy: +remi.lapeyre
versions: +Python 3.10, Python 3.7, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33065] IDLE debugger: failure stepping through module loading

[Terry J. Reedy]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Kerrick Staley]

New submission from Kerrick Staley :

Summary:
When you call ast.literal_eval on a string that does not contain valid Python 
code, it raises a SyntaxError. This causes pdb to exit instead of stopping 
execution at the point that the SyntaxError was raised.

To reproduce:
1. Create a Python file foo.py with these contents:

import ast
ast.literal_eval('')

2. Run python -m pdb foo.py
3. Type 'c' and hit enter.

Expected behavior:
pdb drops into a shell in ast.py at the point where the SyntaxError occurred.

Actual behavior:
The program exits, and a SyntaxError traceback 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

___
Python tracker 
<https://bugs.python.org/issue40403>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33065] IDLE debugger: failure stepping through module loading

[Timothy Geiser]

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 Repr instance, but 
reprlib makes it's own for us to use).

I get a nice boring and not-crashy result in the debug window for Locals:

data   b''
self   

Thanks for the fix, Terry!
I shouldn't expect any strange side-effects from this, should I?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33065] IDLE debugger: failure stepping through module loading

[ppperry]

Change by ppperry :


--
nosy:  -ppperry

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33065] IDLE debugger: failure stepping through module loading

[Terry J. Reedy]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33065] IDLE debugger: failure stepping through module loading

[Terry J. Reedy]

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 calls .repr1, and that calls .repr_xxx, where 
xxx is one of the 'common' builtin classes or 'instance'.

The latter is used for all user classes.  It calls __builtins__.repr, but 
guarded by 'try...except Exception' since user classes may cause exceptions.  
The except clause returns an alternative type and id string, like 
object.__repr__.  (That alternative could also raise, but much less often.  Any 
of the examples above should run if IDLE were started from a command line with 
'python -m idlelib -n'.

When user code is run in a separate process, the code that interacts with user 
object must also run in the separate process.  debugger.Idb is moved and the 
code in debugger_r is added, some in each process.  Of concern here is that the 
GUI code that displays global or local values is passed a dict proxy instead of 
an actual namespace dict.  The proxy __getitem__ for d[key] makes an rpc call 
to through the socket connection to code in the user process.  That returns not 
the object itself but a string representation.  It does so with an unguarded 
repr call.

IDLE intentionally removes traceback lines added by IDLE (and pdb, if used), so 
that tracebacks look mostly the same as in standard CPython.  But that is a 
handicap when there is a bug in IDLE.  A traceback ending with 
  File .../idlelib/debugger_r, line 173, in dict_item
value = repr(value)
AttributeError: ...

would have been a big help here.  I am thinking about how to selectively 
disable traceback cleanup.

In any case, I believe the solution is to import reprlib in debugger_r also and 
add 'reprlib.Repr' before 'repr' in the line above.

--
versions: +Python 3.9

___
Python tracker 
<https://bugs.python.org/issue33065>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33065] IDLE debugger: failure stepping through module loading

[Timothy Geiser]

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 for __repr__ to assume that __init__ is indeed 
finished), the debugger either needs wait until __init__ has completed on any 
given instance before trying to repr it, or otherwise needs to catch a 
potentially very wide range of exceptions that might be raised from calling 
__repr__ so early. I prefer the latter solution, since any buggy code that 
(effectively) crashes on it's __repr__ (for whatever reason) will probably 
bring the debugger to it's knees.
I played around with pdb directly and can sort of get the same thing if I ask 
for __repr__ too early:

 1 Python 3.8.2 (tags/v3.8.2:7b3ab59, Feb 25 2020, 23:03:10) [MSC v.1916 64 bit 
(AMD64)] on win32
 2 Type "help", "copyright", "credits" or "license" for more information.
 3 >>> import data
 4 >>> import pdb
 5 >>> pdb.run("data.BinaryData(b'some data')")
 6 > (1)()
 7 (Pdb) step
 8 --Call--
 9 > c:\users\geitd\documents\python\data.py(4)__init__()
10 -> def __init__(self, data):
11 (Pdb) p self
12 (Pdb) p BinaryData.__repr__(self)
13 *** AttributeError: 'BinaryData' object has no attribute 'length'
14 (Pdb) step
15 > c:\users\geitd\documents\python\data.py(5)__init__()
16 -> if not data:
17 (Pdb) step
18 > c:\users\geitd\documents\python\data.py(7)__init__()
19 -> if len(data) <= 1:
20 (Pdb) step
21 > c:\users\geitd\documents\python\data.py(10)__init__()
22 -> self.data = data
23 (Pdb) step
24 > c:\users\geitd\documents\python\data.py(11)__init__()
25 -> self.length = len(data)
26 (Pdb) p self
27 (Pdb) p BinaryData.__repr__(self)
28 *** AttributeError: 'BinaryData' object has no attribute 'length'
29 (Pdb) step
30 --Return--
31 > c:\users\geitd\documents\python\data.py(11)__init__()->None
32 -> self.length = len(data)
33 (Pdb) p self
34 
35 (Pdb) p BinaryData.__repr__(self)
36 ''

Note that line 11 didn't return anything, but didn't have any bad results, 
whereas the way I phrased line 12 gave the exact same error the IDLE debugger 
threw.
Lines 26 and 27 towards the end of __init__ came out the same, but after the 
--Return-- on 30, either phrasing gives what you'd expect.
I suppose the TL;DR is to take the mechanism that gives the correct behavior of 
'p self' in pdb and copy it over to the IDLE debugger (or whatever other 
mechanism is necessary).

Is this enough for you to work from?

--
Added file: https://bugs.python.org/file49082/data.py

___
Python tracker 
<https://bugs.python.org/issue33065>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33065] IDLE debugger: failure stepping through module loading

[Terry J. Reedy]

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.  What I need is a file that I can download elsewhere, load into 
IDLE, run from a branch for this issue, and edit and rerun.  From the 
traceback, it appears that it might be as simple as 

class BinaryData:
def __init__(self, bd):


BinaryData(b'')

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33065] IDLE debugger: failure stepping through module loading

[Timothy Geiser]

Timothy Geiser  added the comment:

I wish I could be more helpful than to just pipe up with a "this bug affects 
me, too," note, but wanted to poke this bug report since it's been dormant for 
14 months.
With Python 3.8.2 I tried using the pgpdump module (version 1.5, installed 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 recent call last):
  File "", line 1, in 
pgpdump.BinaryData(b'')
  File "C:\Python38\lib\site-packages\pgpdump\data.py", line 13, in __init__
if not data:
  File "C:\Python38\lib\site-packages\pgpdump\data.py", line 13, in __init__
if not data:
  File "C:\Python38\lib\bdb.py", line 88, in trace_dispatch
return self.dispatch_line(frame)
  File "C:\Python38\lib\bdb.py", line 112, in dispatch_line
self.user_line(frame)
  File "C:\Python38\lib\idlelib\debugger.py", line 24, in user_line
self.gui.interaction(message, frame)
AttributeError: 'BinaryData' object has no attribute 'length'

This error only occurs when the Locals checkbox in the debugging window is 
checked - it runs as expected as long as Locals is unchecked (this minimum 
[not]working example throws a "pgpdump.utils.PgpdumpException: no data to 
parse" error, as it should). A longer example with actual data will run for 
several steps while Locals is unchecked, but fails with the first Step once 
Locals is checked. A side note is that the specific error here is that the 
class BinaryData is being asked about it's 'length', rather than the OP's error 
of _ModuleLock not having a 'name'
Is there anything else I can do to help fix this, given that I'm not familiar 
with programming bdb or the IDLE debugger GUI?

--
nosy: +geitda

___
Python tracker 
<https://bugs.python.org/issue33065>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Terry J. Reedy]

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, Python 3.6

___
Python tracker 
<https://bugs.python.org/issue24816>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Terry J. Reedy]

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, Python 3.6

___
Python tracker 
<https://bugs.python.org/issue24818>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Awaiting coroutines inside the debugger (PDB)

[darthdeus]

Hi everyone,

this question is sort of in response to this issue
https://github.com/gotcha/ipdb/issues/174. I've noticed that there was
recently added support for an asyncio repl (run via `python -m
asyncio`), which allows the use of `await` directly on coroutine objects
in the REPL.

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]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15347] IDLE - remove debugger 'interacting'

[Terry J. Reedy]

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 is whether to apply remove-interacting-debugger.patch, 
which was aimed at the deprecated but not removed -n mode.

--
nosy:  -Saimadhav.Heblikar, roger.serwy
title: IDLE - does not close if the debugger was active -> IDLE - remove 
debugger 'interacting'
versions: +Python 3.9 -Python 2.7, Python 3.4, Python 3.5, Python 3.6

___
Python tracker 
<https://bugs.python.org/issue15347>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Stéphane Wirtel]

Stéphane Wirtel  added the comment:

Thank you for your PR,

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Stéphane Wirtel]

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/af5ef3e1077bc2ed177a7c8598f8ecc756ecf6f9


--
nosy: +matrixise

___
Python tracker 
<https://bugs.python.org/issue33882>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[miss-islington]

Change by miss-islington :


--
pull_requests: +12991

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Éric Araujo]

É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


--
nosy: +eric.araujo

___
Python tracker 
<https://bugs.python.org/issue33882>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36550] Avoid creating AttributeError exceptions in the debugger

[daniel hahler]

New submission from daniel hahler :

pdb should try (hard) to avoid creating unnecessary exceptions, e.g. 
``AttributeError`` when looking up commands, since this will show up in 
exception chains then (as "'Pdb' object has no attribute 'do_foo'").

See https://github.com/python/cpython/pull/4666 for an older PR in this regard.

My use case is to display the traceback for exceptions caused within/via 
Pdb.default(), to see more context when running code from pdb's prompt 
directly, where currently it would only display the exception itself.

--
components: Library (Lib)
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.org/issue36550>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36550] Avoid creating AttributeError exceptions in the debugger

[daniel hahler]

Change by daniel hahler :


--
keywords: +patch
pull_requests: +12643
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Lawrence]

Change by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Terry J. Reedy]

Terry J. Reedy  added the comment:

The squeezer feature added last summer can be used to copy large output in 
Shell to the clipboard.  '>>> [None]*1' results in a squeezer label 
representing 750 wrapped lines.  Note that pasting into a new editor disables 
it for awhile.  (Editor 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 squeezed, at a 
much lower threashhold than in Shell.  It is designed for values of, say, 40 
chars or less.  'Large' values could then be copied to clipboard or displayed 
in a separate viewer.

--
versions: +Python 3.8 -Python 3.4

___
Python tracker 
<https://bugs.python.org/issue24090>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33065] IDLE debugger: failure stepping through module loading

[Terry J. Reedy]

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/issue33065>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35690] IDLE: Fix and test debugger.

[anthony shaw]

Change by anthony shaw :


--
keywords: +patch
pull_requests: +10971
stage: needs patch -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35690] IDLE: Fix and test debugger.

[Terry J. Reedy]

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 need to 
determine that now.)

--
messages: 333267
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE: Fix and test debugger.
type: behavior
versions: Python 3.7, Python 3.8

___
Python tracker 
<https://bugs.python.org/issue35690>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35690] IDLE: Fix and test debugger.

[Terry J. Reedy]

Change by Terry J. Reedy :


--
assignee:  -> terry.reedy
components: +IDLE

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

ANN: elicit CLI framework with enhanced debugger 1.7

[kdart]

I really like the exception chaining feature of Python 3. I also like the fact 
that an exception instance now has access to the traceback, making it the only 
object you need to start a debugging session from an exception. 

However, the stock pdb module still does not make it easy to inspect 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" exceptions, respectively. 

The elicit framework is a CLI framework that the debugger uses (replaces cmd). 
It has no other dependencies itself. 

To get this feature you should enter the debugger from the function 
"from_exception(exc)". The "post_mortem" function only takes a traceback, so 
you lose the active exception in some cases. 

-- 
https://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

[issue33065] IDLE debugger: failure stepping through module loading

[Terry J. Reedy]

Change by Terry J. Reedy :


--
versions:  -Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34870] Core dump when Python VSCode debugger is attached

[Terry J. Reedy]

Change by Terry J. Reedy :


--
resolution:  -> third party
stage:  -> resolved
status: open -> closed
type:  -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34870] Core dump when Python VSCode debugger is attached

[Steve Dower]

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34870] Core dump when Python VSCode debugger is attached

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Steve, are you responsible for VSCode and Python?

--
nosy: +steve.dower, terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34870] Core dump when Python VSCode debugger is attached

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +xtreak

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34870] Core dump when Python VSCode debugger is attached

[Per Lundberg]

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 it through).

The program in question is this: 
https://github.com/hiboxsystems/trac-to-gitlab/blob/master/migrate.py

To help in the debugging of this, I installed python2.7-dbg and gdb-python2 on 
my Debian machine, and re-ran the script using this version. Here is the GDB 
output when analyzing the backtrace:

$ gdb /usr/bin/python2.7-dbg core
GNU gdb (Debian 8.1-4+b1) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/python2.7-dbg...done.
[New LWP 19749]
[New LWP 19744]
[New LWP 19747]
[New LWP 19754]
[New LWP 19751]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/bin/python2.7-dbg -m ptvsd --host localhost --port 
43959 migrate.py --only'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  PyEval_EvalFrameEx (f=0x7f815c002310, throwflag=0) at ../Python/ceval.c:3347
3347if (tstate->frame->f_exc_type != NULL)
[Current thread is 1 (Thread 0x7f815bfff700 (LWP 19749))]


The python backtrace looks like this:

(gdb) py-bt
Traceback (most recent call first):
  File "/usr/lib/python2.7/threading.py", line 371, in wait
self._acquire_restore(saved_state)
  File "/usr/lib/python2.7/Queue.py", line 177, in get
self.not_empty.wait(remaining)
  File 
"/home/per/.vscode/extensions/ms-python.python-2018.8.0/pythonFiles/experimental/ptvsd/ptvsd/_vendored/pydevd/_pydevd_bundle/pydevd_comm.py",
 line 458, in _on_run
cmd = self.cmdQueue.get(1, 0.1)
  File 
"/home/per/.vscode/extensions/ms-python.python-2018.8.0/pythonFiles/experimental/ptvsd/ptvsd/_vendored/pydevd/_pydevd_bundle/pydevd_comm.py",
 line 319, in run
self._on_run()
  File "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner
self.run()
  File "/usr/lib/python2.7/threading.py", line 774, in __bootstrap
self.__bootstrap_inner()


And the C-level backtrace:

(gdb) bt 
#0  PyEval_EvalFrameEx (f=Frame 0x7f815c002310, for file 
/usr/lib/python2.7/threading.py, line 371, in wait (), throwflag=0)
at ../Python/ceval.c:3347
#1  0x5624534af42c in PyEval_EvalCodeEx (co=0x7f816216e7d0, 
globals={'current_thread': None, '_BoundedSemaphore': None, 
'currentThread': None, '_Timer': None, '_format_exc': None, 'Semaphore': None, 
'_deque': None, 'activeCount': None, '_profile_hook': None, '_sleep': None, 
'_trace_hook': None, 'ThreadError': None, '_enumerate': None, 
'_start_new_thread': None, 'BoundedSemaphore': None, '_shutdown': None, 
'__all__': None, '_original_start_new_thread': None, '_Event': None, 
'active_count': None, '__package__': None, '_Condition': None, '_RLock': None, 
'_test': None, 'local': None, '__doc__': None, 'Condition': None, '_Verbose': 
None, '_DummyThread': None, 'Thread': None, 'warnings': None, '__builtins__': 
{'bytearray': None, 'IndexError': None, 'all': None, 'help': None, 'vars': 
None, 'SyntaxError': None, 'unicode': None, 'UnicodeDecodeError': None, 
'memoryview': None, 'isinstance': None, 'copyright': None, 'NameError': None, 
'BytesWarning': None, 'dict': None, 'input': None, 'oct': None, 'bin': None, 
'SystemExit': None, 'StandardError': No
 ne, 'format': None, 'repr': None, 'sor...(truncated), locals=0x0, 
args=0x562454463068, argcount=2, 
kws=0x562454463078, kwcount=0, defs=0x7f8162116408, defcount=1, 
closure=0x0) at ../Python/ceval.c:3604
#2  0x5624534b23a7 in fast_function (func=, pp_stack=0x7f815bffd3e8, n=2, na=2, nk=0)
at ../Python/ceval.c:4467
#3  0x5624534b1f8a in call_function (pp_stack=0x7f815bffd3e8, oparg=1) at 
../Python/ceval.c:4392
#4  0x5624534ac45d in PyEval_EvalFrameEx (
f=Frame 0x562454462eb0, for file /usr/lib/python2.7/Queue.py, line 177, in 
get (self=, maxsize=0, all_tasks_done=<_Condition(_Verbose__verbose=False, 
_Condition__lock=, acquire=, 
_Condition__waiters=[], release=) at remote 0x7f81

[issue33065] IDLE debugger: failure stepping through module loading

[ppperry]

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 tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com