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

Variables section only shows 'Invalid variable attributes'. #699

Closed
bartgenuit opened this issue Aug 18, 2021 · 2 comments
Closed

Variables section only shows 'Invalid variable attributes'. #699

bartgenuit opened this issue Aug 18, 2021 · 2 comments
Labels
bug Something isn't working

Comments

@bartgenuit
Copy link

Environment data

  • debugpy version: 1.4.1 (run import debugpy; print(debugpy.__version__) if uncertain)
  • OS and version: Windows 10, 2004, build 19041.1165
  • Python version (& distribution if applicable, e.g. Anaconda): 3.7.11
  • Using VS Code or Visual Studio: VS Code (version 1.59.0)

Actual behavior

Variables section shows no variables, show error message 'Invalid variable attributes' instead. This seems to be with particular Python version (3.7) in combination with particular Flask submodules (session and request).

Expected behavior

Variables shown in the variable section of VS Code.

Steps to reproduce:

  1. Install Remote-Container extension (ms-vscode-remote.remote-containers, tested with v0.191.1).
  2. Clone the 'Try Python remote container' repository:
    git clone https://github.com/microsoft/vscode-remote-try-python.git
  3. Set the Python version VARIANT: "3.7" in .devcontainer/devcontainer.json.
  4. Build and run container (e.g. VSCode > F1 > Remote-Containers: Open Folder in container, then select the repository we just downloaded)
  5. Modify app.py to trigger the behavior:
from flask import Flask
from flask import session
from flask import request
app = Flask(__name__)
breakpoint()

@app.route("/")
def hello():
    return app.send_static_file("index.html")
  1. Start debugging with F5.
@int19h int19h added the bug Something isn't working label Aug 18, 2021
@int19h
Copy link
Contributor

int19h commented Aug 18, 2021

This also reproduces locally. The relevant bit from debugpy logs:

D+00002.047: Server[1] --> {
                 "pydevd_cmd_id": 502,
                 "seq": 52,
                 "type": "response",
                 "request_seq": 17,
                 "success": true,
                 "command": "variables",
                 "body": {
                     "variables": [
                         {
                             "name": "<error>",
                             "value": "Traceback (most recent call last):\n  File \"c:\\Users\\pminaev\\.vscode\\extensions\\ms-python.python-2021.8.1105858891\\pythonFiles\\lib\\python\\debugpy\\_vendored\\pydevd\\_pydevd_bundle\\pydevd_comm.py\", line 776, in internal_get_variable_json\n    variables.append(child_var.get_var_data(fmt=fmt))\n  File \"c:\\Users\\pminaev\\.vscode\\extensions\\ms-python.python-2021.8.1105858891\\pythonFiles\\lib\\python\\debugpy\\_vendored\\pydevd\\_pydevd_bundle\\pydevd_suspended_frames.py\", line 51, in get_var_data\n    self.value, to_string=safe_repr)\n  File \"c:\\Users\\pminaev\\.vscode\\extensions\\ms-python.python-2021.8.1105858891\\pythonFiles\\lib\\python\\debugpy\\_vendored\\pydevd\\_pydevd_bundle\\pydevd_xml.py\", line 298, in get_variable_details\n    _type, type_name, resolver = get_type(v)\n  File \"c:\\Users\\pminaev\\.vscode\\extensions\\ms-python.python-2021.8.1105858891\\pythonFiles\\lib\\python\\debugpy\\_vendored\\pydevd\\_pydevd_bundle\\pydevd_xml.py\", line 151, in get_type\n    return self._get_type(o, type_object, type_name)\n  File \"c:\\Users\\pminaev\\.vscode\\extensions\\ms-python.python-2021.8.1105858891\\pythonFiles\\lib\\python\\debugpy\\_vendored\\pydevd\\_pydevd_bundle\\pydevd_xml.py\", line 154, in _get_type\n    resolver = self._type_to_resolver_cache.get(type_object)\nTypeError: unhashable type: 'LocalProxy'\n",
                             "type": "<error>"
                         }
                     ]
                 }
             }

The LocalProxy type mentioned appears to be werkzeug.local.LocalProxy; both session and request have this type.

@int19h
Copy link
Contributor

int19h commented Aug 18, 2021

The underlying problem is that this:

hash(session.__class__)

fails, because session.__class__ is not actually a type object in this case. It appears to be this Werkzeug issue:

pallets/werkzeug#2188

That said, we should be able to gracefully handle stuff like this, since any type can redefine __class__ in a similar way. The easiest would probably be to check if the returned value is a type, and whether the object queried is actually an instance of that type; if not, fall back to type().

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants