Python debugger cannot display source for scripts #45955

New Issue

Geoffrey Bantle · 2015-08-29T23:49:44+02:00

Geoffrey Bantle commented

2015-08-29 23:49:44 +02:00

System Information:

Windows 7 Enterprise 64 bit
Blender 2.75a 64 bit official windows build
Python 3.4.2 64 bit official windows build from python.org

Python debugger cannot display source for scripts. To reproduce, run the attached script "bug.py" from command line like this:

blender.exe --background --python bug.py

1
2

(7)()

(Pdb)

Compare this to output from python:

python.exe bug.py

1
2

c:\sandbox\bug.py(7)()

print(3)
(Pdb)

I also tested and reproduced the same bug with the ipdb and pycharm debuggers.

bug.py

System Information: Windows 7 Enterprise 64 bit Blender 2.75a 64 bit official windows build Python 3.4.2 64 bit official windows build from python.org Python debugger cannot display source for scripts. To reproduce, run the attached script "bug.py" from command line like this: blender.exe --background --python bug.py 1 2 > <string>(7)<module>() (Pdb) Compare this to output from python: python.exe bug.py 1 2 > c:\sandbox\bug.py(7)<module>() - > print(3) (Pdb) I also tested and reproduced the same bug with the ipdb and pycharm debuggers. [bug.py](https://archive.blender.org/developer/F229070/bug.py)

Geoffrey Bantle commented

2015-08-29 23:49:44 +02:00

Changed status to: 'Open'

Campbell Barton was assigned by Geoffrey Bantle

2015-08-29 23:49:44 +02:00

Geoffrey Bantle commented

2015-08-29 23:49:44 +02:00

Added subscriber: @gbantle-3

Bastien Montagne commented

2015-08-30 00:07:05 +02:00

Added subscriber: @mont29

Bastien Montagne commented

2015-08-30 00:07:05 +02:00

Changed status from 'Open' to: 'Archived'

Bastien Montagne closed this issue

2015-08-30 00:07:05 +02:00

Bastien Montagne commented

2015-08-30 00:07:05 +02:00

Thanks for the report, but no bug here… Embedding python implies some differences from the vanilla interpreter - here Blender reads given py scripts and feeds interpreter with that text, so py indeed does not have access to the file itself (for windows only, due to likely different versions between Blender C lib and python C lib - sigh).

Thanks for the report, but no bug here… Embedding python implies some differences from the vanilla interpreter - here Blender reads given py scripts and feeds interpreter with that text, so py indeed does not have access to the file itself (for windows only, due to likely different versions between Blender C lib and python C lib - *sigh*).

Geoffrey Bantle commented

2015-08-30 00:23:00 +02:00

Hi Bastien,

Thank you for the quick response.

Am I to understand this means it's simply not possible to debug python scripts on windows? Is this limitation documented somewhere?

Hi Bastien, Thank you for the quick response. Am I to understand this means it's simply not possible to debug python scripts on windows? Is this limitation documented somewhere?

Bastien Montagne commented

2015-08-30 08:35:46 +02:00

It’s not impossible at all, you just do not have access to main file's name in this case, that’s all. Should not be a big issue, since you know which file you passed to Blender's options. ;)

Geoffrey Bantle commented

2015-08-30 19:49:45 +02:00

Hi Bastien,

Thanks for the response.

I don't fully agree that since the developer knows the name of the source file all is well, although it certainly helps. I think the relevant point is that since pdb doesn't know the name of the file it no longer works as intended and pdb ships with blender on windows.

Even more interesting, say you don't want to use pdb (which admittedly is not too useful compared to more advanced debuggers), it seems this same issue prevents stack traces from printing properly when unhandled exceptions are thrown. Compare what happens when you run the attached script bug2.py in Blender to what happens when you run it with python.

Blender:

Traceback (most recent call last):

File "<string>", line 1, in <module>
File "<string>", line 17, in <module>
File "<string>", line 2, in a
File "<string>", line 6, in b
File "<string>", line 10, in c
File "<string>", line 14, in d

ZeroDivisionError: division by zero

Blender quit

Python:

Traceback (most recent call last):

File "bug2.py", line 17, in <module>
  a()
File "bug2.py", line 2, in a
  b()
File "bug2.py", line 6, in b
  c()
File "bug2.py", line 10, in c
  d()
File "bug2.py", line 14, in d

1/0

ZeroDivisionError: division by zero

Admittedly all is not lost since the line numbers are preserved and you can cross reference it with your source file by hand to see the actual content of the offending line. However the way Blender does it right now is not too useful when you just want to get a quick look at the error and the code that caused it. Further it may be quite confusing to someone who doesn't know the technical reasons behind this behavior.

Regardless, my motivation here is simply to advocate for a solution that helps others who might run into this same issue in the future. Thanks to your help I know what the problem is and can easily work around it (I just wrote a wrapper which imports my other code that can then be debugged as normal). However this was after quite a bit of confusion on my part and tinkering with the configuration of my debugger. It would be nice if others don't have to go through the same thing in the future.

Hi Bastien, Thanks for the response. I don't fully agree that since the developer knows the name of the source file all is well, although it certainly helps. I think the relevant point is that since pdb doesn't know the name of the file it no longer works as intended and pdb ships with blender on windows. Even more interesting, say you don't want to use pdb (which admittedly is not too useful compared to more advanced debuggers), it seems this same issue prevents stack traces from printing properly when unhandled exceptions are thrown. Compare what happens when you run the attached script [bug2.py](https://archive.blender.org/developer/F229214/bug2.py) in Blender to what happens when you run it with python. Blender: Traceback (most recent call last): ``` File "<string>", line 1, in <module> File "<string>", line 17, in <module> File "<string>", line 2, in a File "<string>", line 6, in b File "<string>", line 10, in c File "<string>", line 14, in d ``` ZeroDivisionError: division by zero Blender quit Python: Traceback (most recent call last): ``` File "bug2.py", line 17, in <module> a() File "bug2.py", line 2, in a b() File "bug2.py", line 6, in b c() File "bug2.py", line 10, in c d() File "bug2.py", line 14, in d ``` 1/0 ZeroDivisionError: division by zero Admittedly all is not lost since the line numbers are preserved and you can cross reference it with your source file by hand to see the actual content of the offending line. However the way Blender does it right now is not too useful when you just want to get a quick look at the error and the code that caused it. Further it may be quite confusing to someone who doesn't know the technical reasons behind this behavior. Regardless, my motivation here is simply to advocate for a solution that helps others who might run into this same issue in the future. Thanks to your help I know what the problem is and can easily work around it (I just wrote a wrapper which imports my other code that can then be debugged as normal). However this was after quite a bit of confusion on my part and tinkering with the configuration of my debugger. It would be nice if others don't have to go through the same thing in the future.

Campbell Barton commented

2015-08-31 15:26:48 +02:00

Hi @gbantle-3, we had a surprising amount of trouble with Python on Windows, (can't use PyRun_File because of incompatible FILE structs), nevertheless, this is possible to support - looking into it.

Hi @gbantle-3, we had a surprising amount of trouble with Python on Windows, (can't use `PyRun_File` because of incompatible `FILE` structs), nevertheless, this is possible to support - looking into it.

blender-admin commented

2015-08-31 15:41:13 +02:00

This issue was referenced by 5f64b77ca5

This issue was referenced by 5f64b77ca5235465b52183d2ea519606253a354e

Campbell Barton commented

2015-08-31 15:49:44 +02:00

Changed status from 'Archived' to: 'Resolved'

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Python debugger cannot display source for scripts #45955