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
569 stars 50 forks source link

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

Open m-deg opened 5 months ago

m-deg commented 5 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 5 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 4 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 3 months ago

Encountering the same issue. Started occuring after updating MacOS.

joeldrotleff commented 3 months ago

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

joeldrotleff commented 3 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 3 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 3 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.

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 3 months 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 3 months 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 3 months 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 3 months ago

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

kirubeltadesse commented 3 months ago

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

kindermax commented 3 months 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 3 months 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 3 months 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)

collindutter commented 1 month ago

Also facing this. If I use nvim-dap-python, it works:

    require('dap-python').setup '/Users/me/.local/share/nvim/mason/packages/debugpy/venv/bin/python'

But using mason-nvim-dap does not:

    require('mason-nvim-dap').setup {
      ensure_installed = {},
      automatic_installation = true,
      handlers = {
        python = function(source_name)
          dap.adapters.python = {
            type = 'executable',
            command = vim.fn.exepath 'debugpy-adapter',
          }

          dap.configurations.python = {
            {
              type = 'python',
              request = 'launch',
              name = 'Launch file',
              program = '${file}',
            },
          }
        end,
      },
    }

Based on this PR, it seems like an issue on mason-nvim-dap.

toryvan commented 1 month ago

@collindutter This helped me. I'm not even using nvim-dap-python, I'm just sorta doing everything manually. I installed the mason based debugpy and pointed my config to that, and it worked.

I was getting the issue with

Python 3.8.19 (default, Oct  1 2024, 14:18:16)
[Clang 15.0.0 (clang-1500.3.9.4)] on darwin

but the mason debugpy interpreter is

Python 3.8.16 (default, Apr 29 2024, 10:58:23)
[Clang 15.0.0 (clang-1500.3.9.4)] on darwin

Maybe later I'll see if there is any special about the mason version, or if there is just a problem with python 3.8.19 and not with 3.8.16.

In both cases I have debugpy==1.8.7

I believe I am now making use of the fact the debugpy runner is using a different interpreter from my actual interpreter. (if that made any sense).

Now I have this, I simplified it a bunch, removing callbacks while debugging. Probably don't need the timeout, issues around that were red herrings.

        dap.adapters.python = {
            type = "executable",
            -- command = "/Users/me/vdev/project/virtualenv/bin/python",
            command = "/Users/me/.local/share/nvim/mason/packages/debugpy/venv/bin/python",
            args = { "-m", "debugpy.adapter" },
            options = {
                source_filetype = "python",
                timeout = 30000,
            },
        }

        dap.configurations.python = {
            {
                type = "python",
                request = "launch",
                name = "Launch file",
                program = "${file}",
                pythonPath = "/Users/me/vdev/project/virtualenv/bin/python",
            },
        }

I am doing a fresh dap install, and wow was I ever barking up the wrong tree for the last 3 hours. Thanks!

Yonace commented 1 week 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: chrisgrieser/nvim-kickstart-python#10 (comment))

Your solution helped a lot; your fix worked well. I added the following plugin: { "ellisonleao/dotenv.nvim", init = function() require("dotenv").setup({ enable_on_load = true, -- Will load your .env file upon loading a buffer verbose = false, }) end, }, However, I was curious why this fixed the issue and why the debugger was only crashing on Macs. It turns out that my ~/.zprofile had multiple Python paths that I was unaware of—specifically, older Python paths and the system Python paths. I think these conflicting paths were causing the debugger to crash.

I deleted the older paths and ensured that my current Python path is placed above the system paths in the ~/.zprofile. This completely fixed the issue—my debugger is no longer crashing, and I was able to remove the dotenv plugin.

Thank you

kindermax commented 6 days ago

@Yonace, it seems like this is relly the issue on how/where nvim tries to find the right python interpreter for dap. I did not know that zprofile somehow influences nvim in that task.