nvim-gdb
nvim-gdb copied to clipboard
code window is empty when debugging with 'master' branch
Hi everyone,
first of all thx for nvim-gdb of course. Yesterday I updated my master branch and ran into the problem I described in the heading. Right now I am using the commit 07aa4b4 which is not affected by that problem.
Bisecting the problem resulted in the following:
9952039dd022ebe40802a006c2a43c8e88594d7f is the first bad commit
commit 9952039dd022ebe40802a006c2a43c8e88594d7f
Author: Anatolii Sakhnik <[email protected]>
Date: Thu Jan 28 23:33:41 2021 +0200
Port parsers to lua
autoload/nvimgdb.vim | 2 +-
lua/nvimgdb.lua | 11 +++
lua/nvimgdb/app.lua | 4 +
lua/nvimgdb/backend/bashdb.lua | 44 ++++++++-
lua/nvimgdb/backend/gdb.lua | 24 +++++
lua/nvimgdb/backend/lldb.lua | 22 +++++
lua/nvimgdb/backend/pdb.lua | 32 ++++++-
lua/nvimgdb/parser_actions.lua | 32 +++++++
lua/nvimgdb/parser_impl.lua | 139 +++++++++++++++++++++++++++++
rplugin/python3/gdb/__init__.py | 25 ------
rplugin/python3/gdb/app.py | 11 +--
rplugin/python3/gdb/backend/base.py | 48 ----------
rplugin/python3/gdb/backend/bashdb.py | 37 --------
rplugin/python3/gdb/backend/gdb.py | 26 ------
rplugin/python3/gdb/backend/lldb.py | 25 ------
rplugin/python3/gdb/backend/parser_impl.py | 137 ----------------------------
rplugin/python3/gdb/backend/pdb.py | 29 ------
rplugin/python3/gdb/parser.py | 28 ------
test/engine.py | 2 +-
19 files changed, 311 insertions(+), 367 deletions(-)
create mode 100644 lua/nvimgdb/parser_actions.lua
create mode 100644 lua/nvimgdb/parser_impl.lua
delete mode 100644 rplugin/python3/gdb/backend/parser_impl.py
delete mode 100644 rplugin/python3/gdb/parser.py
nvim --version gives the following output:
NVIM v0.5.0-dev+1325-gdab6b08a1-dirty
Build type: Gentoo
Lua 5.1
Compilation: /usr/bin/x86_64-pc-linux-gnu-gcc -march=skylake -mtune=skylake -O2 -pipe -frecord-gcc-switches -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=always -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEVEL=1 -I/var/tmp/portage/app-editors/neovim-9999/work/neovim-9999_build/config -I/var/tmp/portage/app-editors/neovim-9999/work/neovim-9999/src -I/usr/include -I/var/tmp/portage/app-editors/neovim-9999/work/neovim-9999_build/src/nvim/auto -I/var/tmp/portage/app-editors/neovim-9999/work/neovim-9999_build/include
Compiled by portage@localhost
Features: +acl +iconv +tui
See ":help feature-compile"
system vimrc file: "/etc/vim/sysinit.vim"
fall-back for $VIM: "/usr/share/nvim"
Run :checkhealth for more info
Here is my spy_ui.log file:
spy_ui.log
Running the tests gave me the following output on my machine: test_run.txt
Maybe it only affects my local machine. Hope that helps. If you need any more input just ask.
Have a good one :)
Thanks for the report! It looks like the prompt can't be recognized.
Could you please run just one test like the following: CI=1 ./run -vv 'test_10_generic.py::test_smoke[backend0]'
Then could you please collect nvimgdb.log and proxy.log? There will be details of the debugger output to determine how the parser failed.
This is really strange. I took the output of your debugger, and I see that the prompt is correctly recognized. I see you're using Gentoo with their build of neovim. Could you please check whether the bug persists when using nvim.appimage from GitHub? What if the regex interpreter behaves differently?
Hmmm.... the good news: with that appimage the master branch works.
here is the output of ./nvim.appimage --version
NVIM v0.5.0-dev+1325-gdab6b08a1
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Compilation: /usr/bin/cc -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -O2 -g -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=always -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEVEL=3 -I/home/runner/work/neovim/neovim/build/config -I/home/runner/work/neovim/neovim/src -I/home/runner/work/neovim/neovim/.deps/usr/include -I/usr/include -I/home/runner/work/neovim/neovim/build/src/nvim/auto -I/home/runner/work/neovim/neovim/build/include
Compiled by runner@fv-az65-759
Features: +acl +iconv +tui
See ":help feature-compile"
system vimrc file: "$VIM/sysinit.vim"
fall-back for $VIM: "
/home/runner/work/neovim/neovim/build/nvim.AppDir/usr/share/nvim"
Run :checkhealth for more info
Well the first thing that caught my eye is the difference between the use of Lua (Lua 5.1 (mine) and LuaJIT 2.1.0-beta3 (AppImage(s)). Dunno though. Which one are you using? To be honest I do not know were the regex interpreter is implemented (Lua maybe?), and changing the Lua library for neovim that Gentoo uses is not something I did before so I cannot do that easily right now.
So all I can say right now: sorry for the inconvenience I got you into and thx for the help.
No worries, it's the Lua interpreter that does the parsing. Neovim is advertised to be using the quicker LuaJIT. And it has better support in Neovim too. So I'd suggest you consider rebuilding your package. It might be enough to just install LuaJIT before rebuilding. On the second thought, the regex was really simple (gdb.lua#30). So I suspect that there may have been something else that malfunctioned. Perhaps, I should take a look at the details some day.
Hey :),
I was curious enough and got my Gentoo system to build neovim with luajit:
NVIM v0.5.0-dev+1326-ge0a01bdf7-dirty
Build type: Gentoo
LuaJIT 2.0.5
Compilation: /usr/bin/x86_64-pc-linux-gnu-gcc -march=skylake -mtune=skylake -O2 -pipe -frecord-gcc-switches -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=always -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEVEL=1 -I/var/tmp/portage/app-editors/neovim-9999/work/neovim-9999_build/config -I/var/tmp/portage/app-editors/neovim-9999/work/neovim-9999/src -I/usr/include -I/var/tmp/portage/app-editors/neovim-9999/work/neovim-9999_build/src/nvim/auto -I/var/tmp/portage/app-editors/neovim-9999/work/neovim-9999_build/include
Compiled by portage@localhost
Features: +acl +iconv +tui
See ":help feature-compile"
system vimrc file: "/etc/vim/sysinit.vim"
fall-back for $VIM: "/usr/share/nvim"
Run :checkhealth for more info
and nvim-gdb works nicely now.
For the errant Gentoo soul that might stumble upon the same problem:
I added a file under my package.use folder with the following content:
*/* LUA_TARGETS: luajit
and added the following content to my neovim file under the same folder:
app-editors/neovim LUA_SINGLE_TARGET: -* luajit
and added the following content to my luv file under the same folder:
# required by app-editors/neovim-9999::gentoo
# required by neovim (argument)
>=dev-lua/luv-1.36.0.0 LUA_SINGLE_TARGET: -* luajit
Then I recompiled neovim and packages whose USE flags changed. I have some big packages still compiling now but It seems to be all calm.
Happy that nvim-gdb now works on master. Looking forward for another vimming period.
Thx sakhnik for your help and for nvim-gdb of course. cya
Excellent, thanks! I'll need to either get a similar build to reproduce and fix the issue or declare that LuaJIT is required in the documentation.
Don't know if it is up to me to close that issue... :)