search

mfussenegger / nvim-dap-python

An extension for nvim-dap, providing default configurations for python and methods to debug individual test methods or classes.
GNU General Public License v3.0
539 stars 48 forks source link

Fatal Python error: _enter_buffered_busy: could not acquire lock for #146

Open m-deg opened 3 months ago

m-deg commented 3 months ago

I am suddenly not able debug a python program. I used to be able to do this. But when I try to start debugger thru nvim-dap, it says "Debug adapter didn't respond, either the adapter is slow or there is a problem with your adapter configuration."

dap.log prints following error:

[ ERROR ] 2024-06-16T22:39:04Z-0700 ] .../deg/.local/share/nvim/lazy/nvim-dap/lua/dap/session.lua:1455 ] "stderr" { args = { "-m", "debugpy.adapter" }, command = "/home/root/.install/.pythonvenv/spacy/bin/python3.11", enrich_config = <function 1>, options = { source_filetype = "python" }, type = "executable" } "Fatal Python error: _enter_buffered_busy: could not acquire lock for <_io.BufferedReader name='<stdin>'> at inter preter shutdown, possibly due to daemon threads\nPython runtime state: finalizing (tstate=0x000055bc6dfa89f8)\n\nCurrent t hread 0x00007f373c081740 (most recent call first):\n <no Python frame>\n" [ INFO ] 2024-06-16T22:39:04Z-0700 ] .../deg/.local/share/nvim/lazy/nvim-dap/lua/dap/session.lua:1428 ] "Process closed" 3 55193

my debugpy version seems to be fine as well:

$ /home/root/.install/.pythonvenv/spacy/bin/python3.11 -m debugpy --version 0.00s - Debugger warning: It seems that frozen modules are being used, which may 0.00s - make the debugger miss breakpoints. Please pass -Xfrozen_modules=off 0.00s - to python to disable frozen modules. 0.00s - Note: Debugging will proceed. Set PYDEVD_DISABLE_FILE_VALIDATION=1 to disable this validation. 1.8.1

Any ideas?

dotunwrap commented 3 months ago

I'm getting this same error. I can't seem to figure out exactly what's causing it either. I've tried a few things, but nothing seems to get rid of it. I will say, though, that I also tried to run my debugpy using solely nvim-dap and disabled nvim-dap-python and the error was still persistent.

curiousyogurt commented 2 months ago

I'm encountering what I think might be the same, or possibly a closely related error. Here it is (from :DapShowLog):

Fatal Python error: _enter_buffered_busy: could not acquire lock for <_io.BufferedReader name='<stdin>'>  ...

I have tried various ways of ensuring the proper version of python is referenced, but to no avail. In my configuration file for nvim-dap, I have:

require('dap-python').setup("/usr/bin/python3")

There is indeed python3 at that location. In addition, /usr/bin/python3 -m debugpy launches without error.

Three additional points:

  1. The same error occurs with a minimal Nvim: nothing but Lazy.vim, Nvim-dap, Nvim-dap-python.
  2. The same error occurs with a minimal test.py: print("Hello").
  3. If I install Nvim-dap-ui and use it, it starts, but then I get kicked out of the fancy windows.

Here is the full log, just in case anyone has any ideas how to follow up with this:

[ ERROR ] 2024-07-12T18:35:15Z-0400 ] .../.local/share/nvim/lazy/nvim-dap/lua/dap/session.lua:1466 ] "stderr"
{ args = { "-m", "debugpy.adapter" },
  command = "/usr/bin/python3",
  enrich_config = <function 1>,
  options = { source_filetype = "python" },
  type = "executable"
}
"Fatal Python error: _enter_buffered_busy: could not acquire lock for <_io.BufferedReader name='<stdin>'> at interpreter shutdown, possibly due to daemon threads\nPython runtime state: finalizing (tstate=0x130e072b0)\n\nCurrent thread 0x00000001f79fcc00 (most recent call first):\n<no Python frame>\n"
[ INFO ] 2024-07-12T18:35:15Z-0400 ] .../.local/share/nvim/lazy/nvim-dap/lua/dap/session.lua:1439 ] "Process closed"

Any help would be greatly appreciated. Thanks.

kristiansordal commented 2 months ago

Encountering the same issue. Started occuring after updating MacOS.

joeldrotleff commented 2 months ago

I'm seeing this as well on latest macOS 14.6, vim 0.10.1, Python 3.12.4

joeldrotleff commented 2 months ago

Ah hmm so I was able to fix this, not sure exactly what did it but the steps I took.

Pretty sure the last step above was the issue, but including it all in case it helps someone.

hmyuuu commented 2 months ago

Getting the same error on 15.0 beta

I did :checkhealth python, it shows

  • Python version: 3.12.4
  • pynvim version: 0.5.0
  • OK Latest pynvim is installed.

it looks good but the debugger still crashes soon.

tkreuder commented 1 month ago

I'm encountering what I think might be the same, or possibly a closely related error. Here it is (from :DapShowLog):

Fatal Python error: _enter_buffered_busy: could not acquire lock for <_io.BufferedReader name='<stdin>'>  ...

I have tried various ways of ensuring the proper version of python is referenced, but to no avail. In my configuration file for nvim-dap, I have:

require('dap-python').setup("/usr/bin/python3")

There is indeed python3 at that location. In addition, /usr/bin/python3 -m debugpy launches without error.

Three additional points:

  1. The same error occurs with a minimal Nvim: nothing but Lazy.vim, Nvim-dap, Nvim-dap-python.
  2. The same error occurs with a minimal test.py: print("Hello").
  3. If I install Nvim-dap-ui and use it, it starts, but then I get kicked out of the fancy windows.

Here is the full log, just in case anyone has any ideas how to follow up with this:

[ ERROR ] 2024-07-12T18:35:15Z-0400 ] .../.local/share/nvim/lazy/nvim-dap/lua/dap/session.lua:1466 ] "stderr"
{ args = { "-m", "debugpy.adapter" },
  command = "/usr/bin/python3",
  enrich_config = <function 1>,
  options = { source_filetype = "python" },
  type = "executable"
}
"Fatal Python error: _enter_buffered_busy: could not acquire lock for <_io.BufferedReader name='<stdin>'> at interpreter shutdown, possibly due to daemon threads\nPython runtime state: finalizing (tstate=0x130e072b0)\n\nCurrent thread 0x00000001f79fcc00 (most recent call first):\n<no Python frame>\n"
[ INFO ] 2024-07-12T18:35:15Z-0400 ] .../.local/share/nvim/lazy/nvim-dap/lua/dap/session.lua:1439 ]   "Process closed"

Any help would be greatly appreciated. Thanks.

Can confirm that i also happens without nvim-dap-python installed. I am just using nvim-dap.

Macbook Pro Intel i9 2019 version with MacOS 14.5

tkreuder commented 1 month ago

Found the following https://github.com/mfussenegger/nvim-dap-python/issues/149 and i do not know, if it is related somehow. I am using a different version of lazy: https://github.com/folke/lazy.nvim.git and not the one mentioned.

tkreuder commented 1 month ago

Ah hmm so I was able to fix this, not sure exactly what did it but the steps I took.

  • Specify my python in init.py: vim.g.python3_host_prog = vim.fn.expand('~/.virtualenvs/debugpy/bin/python'). Not sure if this is required but I did it because opening .py files was super slow before.
  • Make sure nvim-dap-python's path is the same as above
  • I did :checkhealth python and it complained that 'neovim' wasn't installed. So I did source/bin/activate in the virtualenv above, then pip install neovim

Pretty sure the last step above was the issue, but including it all in case it helps someone.

For me it also showed that python is missing neovim, but after i installed it and :checkhealth python has no issues any more, it still did not work. I also tried the paths part you mentioned @joeldrotleff (Any other ideas?).

tkreuder commented 1 month ago

I was able to narrow it down: The Python: Current File works fine of my launch.json (see below). Python: FastAPI does give me:

 command = "/Users/xyz/.local/share/nvim/mason/bin/debugpy-adapter",
  type = "executable"
}   "Fatal Python error: _enter_buffered_busy: could not acquire lock for <_io.BufferedReader name='<stdin>'> at interpreter shutdown, possibly due to daemon threads\nPython runtime state: finalizing (tstate=0x000000010dd2f3a8)\n"
[ ERROR ] 2024-08-07T23:59:45Z+0200 ] ...uder/.local/share/nvim/lazy/nvim-dap/lua/dap/session.lua:1466 ]    "stderr"    {
  command = "/Users/xyz/.local/share/nvim/mason/bin/debugpy-adapter",
  type = "executable"
}   "\nCurrent thread 0x00007ff84d8dbfc0 (most recent call first):\n  <no Python frame>\n"
[ INFO ] 2024-08-07T23:59:45Z+0200 ] ...uder/.local/share/nvim/lazy/nvim-dap/lua/dap/session.lua:1439 ] "Process closed"    41443

using this launch.json which works fine with vscode:


{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Python: FastAPI",
            "type": "python",
            "cwd": "${workspaceFolder}/app",
            "envFile": "${workspaceFolder}/.env",
            "request": "launch",
            "module": "uvicorn",
            "args": [
                "app.main:app",
                "--log-level",
                "debug",
                "--host",
                "0.0.0.0",
                "--reload"
            ],
            "jinja": true,
            "justMyCode": false
        },
        {
            "name": "Python: Current File",
            "type": "python",
            "request": "launch",
            "program": "${file}",
            "console": "integratedTerminal",
            "justMyCode": false,
            "env": {
                "PYTHONPATH": "${workspaceFolder}/app"
            },
            "cwd": "${workspaceFolder}/app"
        }
    ]
}
tkreuder commented 1 month ago

How can I best intercept the calls and see what is causing the issue?

kirubeltadesse commented 1 month ago

I am also experience the same issue. Please let us know if there is a work around this problem.

kindermax commented 1 month ago

Same problem

[ ERROR ] 2024-08-20T20:02:24Z+0300 ] .../max/.local/share/nvim/lazy/nvim-dap/lua/dap/session.lua:1484 ]        "stderr"        {
  args = { "-m", "debugpy.adapter" },
  command = "/Users/max/code/app/.venv/bin/python",
  type = "executable"
}       "Fatal Python error: _enter_buffered_busy: could not acquire lock for <_io.BufferedReader name='<stdin>'> at interpreter shutdown, possibly due to daemon threads\nPython runtime state: finalizing (tstate=0x000000010227c4a0)\n\nCurrent thread 0x00000002035a4c00 (most recent call first):\n  <no Python frame>\n"
[ INFO ] 2024-08-20T20:02:24Z+0300 ] .../max/.local/share/nvim/lazy/nvim-dap/lua/dap/session.lua:1457 ] "Process closed"        35154

My config is

  {
    "jay-babu/mason-nvim-dap.nvim",
    opts = function(_, opts)
      opts.ensure_installed = require("astrocore").list_insert_unique(opts.ensure_installed, {
        "python",
      })
      opts.handlers = {
        function(config)
          -- all sources with no handler get passed here

          -- Keep original functionality
          require("mason-nvim-dap").default_setup(config)
        end,
        python = function(config)
          config.adapters = {
            type = "executable",
            command = "/Users/max/code/app/.venv/bin/python",
            -- command = "/Library/Frameworks/Python.framework/Versions/3.12/bin/python3.12",
            args = {
              "-m",
              "debugpy.adapter",
            },
          }

          config.configurations = {
            {
              type = "python",
              request = "attach",
              name = "Attach app",
              connect = {
                host = "0.0.0.0",
                port = 9977,
              },
              pathMappings = {
                {
                  localRoot = "${workspaceFolder}",
                  remoteRoot = ".",
                },
              },
              justMyCode = true,
            },
          }

          require("mason-nvim-dap").default_setup(config)
        end,
      }
    end,
  },
kindermax commented 1 month ago

Strange, but this works (if remove "jay-babu/mason-nvim-dap.nvim", from config). But I do not know why

  {
    "mfussenegger/nvim-dap-python",
    config = function()
      require("dap-python").setup "~/.local/share/nvim/mason/packages/debugpy/venv/bin/python"
      require("dap-python").test_runner = "pytest"

      table.insert(require("dap").configurations.python, {
        type = "python",
        request = "attach",
        name = "Attach app",
        connect = {
          host = "localhost",
          port = 9977,
        },
        pathMappings = {
          {
            localRoot = "${workspaceFolder}",
            -- localRoot = vim.fn.getcwd(),
            remoteRoot = ".",
          },
        },
        justMyCode = true,
      })
    end,
  },

 ~/.local/share/nvim/mason/packages/debugpy/venv/bin/python --version
Python 3.12.0
tkreuder commented 1 month ago

Strange, but this works (if remove "jay-babu/mason-nvim-dap.nvim", from config). But I do not know why

  {
    "mfussenegger/nvim-dap-python",
    config = function()
      require("dap-python").setup "~/.local/share/nvim/mason/packages/debugpy/venv/bin/python"
      require("dap-python").test_runner = "pytest"

      table.insert(require("dap").configurations.python, {
        type = "python",
        request = "attach",
        name = "Attach app",
        connect = {
          host = "localhost",
          port = 9977,
        },
        pathMappings = {
          {
            localRoot = "${workspaceFolder}",
            -- localRoot = vim.fn.getcwd(),
            remoteRoot = ".",
          },
        },
        justMyCode = true,
      })
    end,
  },
 ~/.local/share/nvim/mason/packages/debugpy/venv/bin/python --version
Python 3.12.0

I did not need to remove that plugin, as it did not solve the issue. For me it was an issue with my .env file (see: https://github.com/chrisgrieser/nvim-kickstart-python/issues/10#issuecomment-2302345855)