Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debuger not working coretly with Django #315

Closed
ManPython opened this issue Jun 26, 2020 · 10 comments
Closed

Debuger not working coretly with Django #315

ManPython opened this issue Jun 26, 2020 · 10 comments

Comments

@ManPython
Copy link

Environment data

Version: 1.46.1
Commit: cd9ea6488829f560dc949a8b2fb789f3cdc05f5d
Date: 2020-06-17T21:13:20.174Z
Electron: 7.3.1
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Windows_NT x64 6.1.7601

Actual behavior

  1. In any start of djnago debug I have errors in stack:
  • exists genericpath.py 19:1 as os.stat(path)
  • _run_code runpy.py 85:1 as exec(code, run_globals)
  • _run_module_as_main runpy.py 193:1 as "main", mod_spec)
  1. Some of logs ptvsd.server-4608
I+00000.000: Windows-7-6.1.7601-SP1 AMD64
             CPython 3.6.8 (64-bit)
             ptvsd 5.0.0a7

I+00000.000: ptvsd.server startup environment:
             
I+00000.016: Won't trace filenames starting with: [
                 "e:\\microsoft\\.vscode\\extensions\\ms-python.python-2019.11.50794\\pythonfiles\\lib\\python\\new_ptvsd\\no_wheels\\ptvsd"
             ]
             Won't trace filenames ending with: [
                 "ptvsd_launcher.py"
             ]
  1. Logs frompydevd.4608
PyDB.dispose_and_kill_all_pydevd_threads (called from: File "e:\Microsoft\.vscode\extensions\ms-python.python-2019.11.50794\pythonFiles\lib\python\new_ptvsd\no_wheels\ptvsd\_vendored\pydevd\_pydevd_bundle\pydevd_api.py", line 946, in _terminate_if_commands_processed)
sending cmd -->           CMD_RETURN {"type": "response", "request_seq": 9, "success": true, "command": "disconnect", "seq": 22, "pydevd_cmd_id": 502}

PyDB.dispose_and_kill_all_pydevd_threads (first call)
PyDB.dispose_and_kill_all_pydevd_threads no commands being processed.
PyDB.dispose_and_kill_all_pydevd_threads killing thread: <PyDBDaemonThread(_terminate_if_commands_processed (pydevd daemon thread), started daemon 3644)>
_terminate_if_commands_processed (pydevd daemon thread) received kill signal
PyDB.dispose_and_kill_all_pydevd_threads killing thread: <WriterThread(pydevd.Writer, started daemon 3256)>
sending cmd -->             CMD_EXIT {"type": "event", "event": "terminated", "seq": 24, "body": {}, "pydevd_cmd_id": 129}

pydevd.Writer received kill signal
PyDB.dispose_and_kill_all_pydevd_threads killing thread: <PyDBCommandThread(pydevd.CommandThread, started daemon 4008)>
pydevd.CommandThread received kill signal
PyDB.dispose_and_kill_all_pydevd_threads killing thread: <CheckAliveThread(pydevd.CheckAliveThread, started 3592)>
pydevd.CheckAliveThread received kill signal
PyDB.dispose_and_kill_all_pydevd_threads killing thread: <ReaderThread(pydevd.Reader, started daemon 6068)>
pydevd.Reader received kill signal
PyDB.dispose_and_kill_all_pydevd_threads waiting for pydb daemon threads to finish
WriterThread: CMD_EXIT received
WriterThread: exit
The following pydb threads may not have finished correctly: pydevd.Reader
PyDB.dispose_and_kill_all_pydevd_threads: finished
Terminating child processes.

Expected behavior

Normal debuging without blocking

Steps to reproduce:

  1. I'm using configuration
            "args": ["runserver", "127.0.0.1:8000", "--traceback", "-v", "3"],
            "django": true,
            "subProcess": true,
            "justMyCode":  false,
            "env": {
               "PTVSD_LOG_DIR":"C:\\Logs",
               "PYDEVD_DEBUG":"True",
               "PYDEVD_DEBUG_FILE":"C:\\Logs\\pydevd.log"
            },
            "logToFile": true,
            //"envFile": "${workspaceRoot}/path/to/virtualenv",
            //"envFile": "${workspaceRoot}\\",
            "debugOptions": [
                "RedirectOutput",       // Whether to redirect stdout and stderr (see pydevd_comm.CMD_REDIRECT_OUTPUT)
                "Django",               // Enables Django Template debugging
                //"Jinja",                // Enables Jinja (Flask) Template debugging
                "FixFilePathCase",      // See FIX_FILE_PATH_CASE in wrapper.py
                //"DebugStdLib",          // Whether to enable debugging of standard library functions
                //"StopOnEntry",          // Whether to stop at first line of user code
                "ShowReturnValue",      // Show return values of functions
            ]
@int19h
Copy link
Contributor

int19h commented Jun 26, 2020

Which exception are you getting?

@ManPython
Copy link
Author

ManPython commented Jun 27, 2020

@int19h as in point 1 (Exception has occurred: FileNotFoundError). the 3 blocking, next steps in debug offering next and app never runing in this way by VSC. In cmd working normaly and no problems. And important.. DJ 2.2.6 ! Damm.. I can't work with new version of DJ coz many old libs are not supported..
I should probably not put more issues around DJ 2.2.6 , hvr.. expeting working in VSC with any enviroment.

@fabioz
Copy link
Collaborator

fabioz commented Jul 24, 2020

@ManPython some questions:

What Python version are you using?

Can you reproduce this with a getting started example or just in your own app?

Can you send the full logs (the partial info in the description isn't really enough to know what's happening)?

Which other libraries do you have installed in the env?

@ManPython
Copy link
Author

@fabioz P 3.8.2 final.

I getting this errors in any simple example and any basic start version of DJ 2.2.6.

Will try prepare logs in next week. In fact there is nothing strange for me in comparision with others working.

About libs, when DJ is basic then in settings nothing more as typical. If you asking about Python then I have many in case I often not using venv - hvr looks not related with this debuging errors. Just maybe take point that I'm using VSC portable and the settings like this:
--user-data-dir=
--extensions-dir=

And.. there are 2 updates again and not sure it's still actual with this error, and logs can be other.

@fabioz
Copy link
Collaborator

fabioz commented Jul 24, 2020

Can you try without any of the debugOptions to see if it makes any difference?

Also, if you set "django"=false in the settings, does it work? (in this case it wouldn't hit template breakpoints, but I'm curious if you have issues in that case).

As a note, we do have a test-case with Django 2.2 and I tried it locally (manually) and it seems to work and hit breakpoints both in regular files as well as templates.

So, when you get the logs, it'd be also nice if you can provide the actual code and steps which you're making to test, to make sure I'm not missing anything here (i.e.: run app, add breakpoints at "xxx, line yyy", open url 127.0.0.1/my_app, expect ...).

@ManPython
Copy link
Author

ManPython commented Jul 28, 2020

  1. This what I getting now.
[WinError 2] .. cant find file : 'E:\\Python36\\python36.zip'

It was produced when changed "django"=false/true. After first meet of this any changes in this true/flase not backing like on 1st post as standard.

Logs are not produced.. so...

import platform
print(platform.python_version())

Python 3.6.8

Version: 1.47.0
Commit: d5e9aa0227e057a60c82568bf31c04730dc15dcd
Date: 2020-07-09T08:02:06.629Z
Electron: 7.3.2
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Windows_NT x64 6.1.7601

This same on (After last update):

Version: 1.47.3
Commit: 91899dcef7b8110878ea59626991a18c8a6a1b3e
Date: 2020-07-23T13:12:49.994Z
Electron: 7.3.2
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Windows_NT x64 6.1.7601

@ManPython
Copy link
Author

No changes if deleted debugOptions, this same as in previous post.

@ManPython
Copy link
Author

@int19h I still don't understand why debugpy can't use normaly Python36\Lib in p36 but need Python36\python36.zip in case that python36.zip not exist just I know python37.zip as p37..
By this we can't work with older projects.

@int19h
Copy link
Contributor

int19h commented Aug 25, 2020

The debugger doesn't decide this. Python itself does. If the debugger is trying to load standard library files from a .zip, this means that you're running some version of Python that's packaged that way.

@ManPython
Copy link
Author

Strange.. but clear now (good to know what problem was). If this how works, then nothing to do with this issue and can be closed.

@int19h int19h closed this as completed Oct 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants