Giter Site home page Giter Site logo

nvim-gdb's Introduction

Test Codacy Badge

GDB for neovim

Gdb, LLDB, pdb/pdb++ and BASHDB integration with NeoVim.

Table of contents

Overview

Taken from the neovim: neovim_gdb.vim

It is instantly usable: type <leader>dd, edit GDB launching command, hit <cr>. Or type <leader>dl to do the same with LLDB backend. Or type <leader>dp to start debugging a python program. Or type <leader>db to start debugging a BASH script.

Also you can record the execution of a program with rr record, and then replay its execution systematically with <leader>dr.

Supported debuggers and operating systems:

Debugger Linux Darwin Windows
GNU gdb
lldb
pdb
BashDB
rr

nvim-gdb

Installation

Check the prerequisites in the script test/prerequisites.py.

Use the branch master for NeoVim ≥ 0.7 or the branch devel to benefit from the latest NeoVim features.

If you use vim-plug, add the following line to your vimrc file:

Plug 'sakhnik/nvim-gdb'

Options

To disable the plugin

let g:loaded_nvimgdb = 1

:GdbStart and :GdbStartLLDB use find and the cmake file API to try to tab-complete the command with the executable for the current file. To disable this set g:nvimgdb_use_find_executables or g:nvimgdb_use_cmake_to_find_executables to 0.

The behaviour of the plugin can be tuned by defining specific variables. For instance, you could overload some command keymaps:

" We're going to define single-letter keymaps, so don't try to define them
" in the terminal window.  The debugger CLI should continue accepting text commands.
function! NvimGdbNoTKeymaps()
  tnoremap <silent> <buffer> <esc> <c-\><c-n>
endfunction

let g:nvimgdb_config_override = {
  \ 'key_next': 'n',
  \ 'key_step': 's',
  \ 'key_finish': 'f',
  \ 'key_continue': 'c',
  \ 'key_until': 'u',
  \ 'key_breakpoint': 'b',
  \ 'set_tkeymaps': "NvimGdbNoTKeymaps",
  \ }

Likewise, you could define your own hooks to be called when the source window is entered and left. Please refer to the online NeoVim help: :help nvimgdb.

Usage

See :help nvimgdb for the complete online documentation. Most notable commands:

Mapping Command Description
<Leader>dd :GdbStart gdb -q ./a.out Start debugging session, allows editing the launching command
<Leader>dl :GdbStartLLDB lldb ./a.out Start debugging session, allows editing the launching command
<Leader>dp :GdbStartPDB python -m pdb main.py Start Python debugging session, allows editing the launching command
<Leader>db :GdbStartBashDB bashdb main.sh Start BASH debugging session, allows editing the launching command
<Leader>dr :GdbStartRR Start debugging session with rr replay.
<F8> :GdbBreakpointToggle Toggle breakpoint in the coursor line
<F4> :GdbUntil Continue execution until a given line (until in gdb)
<F5> :GdbContinue Continue execution (continue in gdb)
<F10> :GdbNext Step over the next statement (next in gdb)
<F11> :GdbStep Step into the next statement (step in gdb)
<F12> :GdbFinish Step out the current frame (finish in gdb)
<c-p> :GdbFrameUp Navigate one frame up (up in gdb)
<c-n> :GdbFrameDown Navigate one frame down (down in gdb)

You can create a watch window evaluating a backend command on every step. Try :GdbCreateWatch info locals in GDB, for istance.

You can open the list of breakpoints or backtrace locations into the location list. Try :GdbLopenBacktrace or :GdbLopenBreakpoints.

Development

The goal is to have a thin wrapper around GDB, LLDB, pdb/pdb++ and BASHDB, just like the official TUI. NeoVim will enhance debugging with syntax highlighting and source code navigation.

The project uses GitHub actions to run the test suite on every commit automatically. The plugin, proxy and screen logs can be downloaded as the artifacts to be analyzed locally.

To ease reproduction of an issue, set the environment variable CI, and launch NeoVim with the auxiliary script test/nvim.py. The screen cast will be written to the log file spy_ui.log. Alternatively, consider recording the terminal script with the ubiquitous command script.

To support development, consider donating:

References

Showcase

GdbStartRR

nvim-gdb + llvm

clone + test

nvim-gdb's People

Contributors

acidtonic avatar adamansky avatar benjaminchristie avatar davxy avatar foonathan avatar kevinhwang91 avatar lanza avatar narice avatar raineszm avatar rgreenblatt avatar rkuester avatar sakhnik avatar sebastianzaha avatar tsjordan-eng avatar voldikss avatar zhoupro avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

nvim-gdb's Issues

[enhancement] stop nvimgdb_config_override when in the debug console

Hi,
I love the feature of overriding keys for debugging and it's in my point of view extremely useful.
But something that could be great would be to stop the overriding when typing things into the command line. an example would be to just try typing start in the gdb command line after opening the debugging tab. I saw (maybe I'm wrong) that the override is disabled when going to another tab, so I guessed it was feasible.

Thanks for your dedication!

Make keymaps and commands local to a debug view

The debugging commands don't make sense outside the debugging session. Set/unset them as the user navigates the tab pages.
Alternatively, make mappings buffer-local. Keep in mind that a user may open buffers in the debug tab page too.

Too many arguments for function

When i started it by ":GdbStart gdb -q -f a.out",i got errors bleow:
Error detected while processing function nvimgdb#Spawn[1]..98_InitMachine:
line 20:
E118: Too many arguments for function: function
E15: Invalid expression: function("s:GdbPaused_continue", data)
line 21:
E118: Too many arguments for function: function
E15: Invalid expression: function("s:GdbPaused_jump", data)
line 22:
E118: Too many arguments for function: function
E15: Invalid expression: function("s:GdbPaused_info_breakpoints", data)
line 23:
E118: Too many arguments for function: function
E15: Invalid expression: function("s:GdbPaused_breakpoint", data)
line 26:
E118: Too many arguments for function: function
E15: Invalid expression: function("s:GdbRunning_pause", data)

Nvim lua lib

Hey!

Your plugin looks pretty nice, I'm giving it a short for my rust code soon!

I noticed you're having quite a bit of dependencies on lua packages that you're installing via install.sh. That's a bit of an uncomfortable situation, imho, and while I can't judge the necessity, I do want to point out to you this PR where we want to improve the developer's experience with lua, and provide functionality as a "lua stdlib". Maybe you want to chime in with your experience :)

E31 NO such mapping

when installed in the beginning. i can debug and saw my code. and F6, F7 step in, out...
and then, after i changed my keymap. there is a E31 error message still happened, even I fallback every.

please help.

in my NeoVim RC

38 Plug 'sakhnik/nvim-gdb' , {'do': './install.sh' }
39
40 let g:nvimgdb_config_override = {
41 \ 'key_next': '',
42 \ 'key_step': '',
43 \ 'key_finish': '',
44 \ 'key_continue': '',
45 \ 'key_until': '',
46 \ 'key_breakpoint': '',}
47
48 let g:nvimgdb_disable_start_keymaps = 1
49 nnoremap dd :GdbStart gdb -q ../bin/iBetter
50 nnoremap ds :GdbDebugStop

got error
screen shot 2018-12-26 at 2 54 47 am

Question about custom bindings

I use cgdb a lot and just come across nvim-gdb, think it may integrate well with my LSP workflow. cgdb is not very helpful reading source code due to the lack of cross references. In nvim + LanguageClient-neovim, I can use ccls for definition/references/hover.

Is it easy to turn the following some cgdb bindings into nvim-gdb maps?

# `;` switches to the source window
# `i` switches to the command window
imap ; <ESC>

## when the focus is in the source window, the following keys can be used
## they are easier to press compared with <F9> ...
map c :continue<CR>
map d :down<CR>
map f :finish<CR>
map s :step<CR>
map u :up<CR>

map v iinfo<Space>locals<CR><ESC>

With cgdb, my cursor mostly stay in the source window. I use d u f c a lot, when I need to eval something, I press i to switch to the command window, enter p foo, press Enter and then ; to go back to the source window.

Do you have suggestions how I can duplicate the workflow with nvim-gdb? As you see, p foo is a time-consuming process. The ideal approach is to stay in the source window, hit some shortcut to evaluate an identifier. cgdb/cgdb#141

By default the gdb window is in the terminal mode (-- TERMINAL --). I know C-\ C-n enters normal mode but it does not seem very convenient...

I think there are many others who don't like bindings. You may consider creating a wiki page describing how to bind these commonly used commands to single-letter keys.

Implement a wrapper for GDB

A tiny python proxy would open PTY to allow issuing server commands to GDB or LLDB outside stdin, and return result programmatically without stdout. Conveniently, GDB allows to bypass command history by prefixing commands with server.
Consider naming custom commands in a specific manner <start,end> for easier concealment.

  • How to bypass history in LLDB?
  • Is it possible to pass commands to LLDB without touching stdin/stdout?
  • Pass all the input to the underlying CLI app
  • Parse command output and cut off everything between x-nvim-gdb- and next GDB/LLDB prompt
  • Move debugger initialization commands to the wrapper

[bug] Messed autocompletion

In the GDB CLI type info <tab> to show the completions. Then type locals.
Expected: info locals executed.
Actual: 'Command not found: local'
It looks like info breakpoints is fired automatically, messing with the interpreter. Need to find a way to distinguish between prompt + pause and prompt + prefix of the next command.

Use random socket addresses

Currently, the addresses are hardcoded to simplify testing with socat.
Make them random temporary files eventually to allow concurrent debugging sessions.

Readme installation command is not correct

I noticed that the command to install the plugin in the readme is not correct, the pipe needs to be escaped with a leading backslash otherwise you get an error (At least it did for me).

The line:
Plug 'sakhnik/nvim-gdb', { 'do': ':!./install.sh | UpdateRemotePlugins' }
Should be replaced by:
Plug 'sakhnik/nvim-gdb', { 'do': ':!./install.sh \| UpdateRemotePlugins' }

I would have changed it myselve but I dont have much experience with git and all that I know is limited to git itself and not github.

Keymaps are overwritten

Taken from the issue's #14 comment:

After starting nvim I usually press ctrl - p to search for the file I want to edit.
:map <C-p> results in the following output: n <C-P> * :FZF<CR>
Typing :GdbStart gdb -q -f <mybinary> starts the the TUI like environment in a new tab.
After my debug session I write quit in the debuggers console. It is not necessary to do anything. Writing quit instantly results in the same issue.
This results in switching to my previous tab where I edited my file.
All keymaps are overwritten from now on.
:map <C-p> results in the following output: No mapping found

These are my settings for this plugin:

" nvim-gdb ((((((((((((((((((((((((((((((((((((((((((((((((
" gdb and lldb wrapper
Plug 'sakhnik/nvim-gdb'
let g:nvimgdb_disable_start_keymaps = 1
" nvim-gdb ))))))))))))))))))))))))))))))))))))))))))))))))

PS: Had the same issue before setting let g:nvimgdb_disable_start_keymaps = 1

Backtrace in lldb causes unwanted jumps to the call stack frames

settings set frame-format has a more global effect than needed.
The alternative target stop-hook add --one-liner 'print(lldb.frame.GetLineEntry())' isn't suitable too, because it wouldn't track navigation in the call stack (up, down).
We need either to work around or to declare a limitation.

Error on GdbStartLLDB

Hi,

I'm getting the following errors when starting GdbStartLLDB with a simple .c program.

"allEven.c" 47L, 1090C
Error detected while processing function <SNR>107_JobOutput[1]..31[15]..32[13]..<SNR>106_GdbRunning_pause[7]..24:
line    1:
E117: Unknown function: chansend
Error detected while processing function <SNR>107_JobOutput[1]..31[15]..32[13]..<SNR>106_GdbRunning_pause[7]..24:
line    1:
E117: Unknown function: chansend
Error detected while processing function <SNR>107_JobOutput[1]..31[15]..32[13]..<SNR>106_GdbRunning_pause[7]..24:
line    1:
E117: Unknown function: chansend
Error detected while processing function <SNR>107_JobOutput[1]..31[15]..32[13]..<SNR>106_GdbRunning_pause[7]..24:
line    1:
E117: Unknown function: chansend

I am on macOS.
lldb --version == lldb-900.0.64

Colors in gdb split

Hey, I saw that its possible to colorize the gdb output with a .gdbinit file like this or this one. Using this with nvim-gdb, my source window stays empty. Is it possible to use such a config file with nvim-gdb?

python3 shows tons of errors

Haven't figured out how to properly debug vimscript/vim-running-python to know what the errors are doing, but this pops up:

Error detected while processing function <SNR>165_OnBufEnter[5]..<SNR>165_GdbPaused_info_breakpoints[27]..<SNR>165_InfoBreakpoints[5]..provider#python3#Call:
line   18:
error caught in request handler 'python_eval ["InfoBreakpoints('/Users/lanza/.dotfiles/dtf', '/var/folders/p5/2m9kg46x21q8h5f9p6tpft64rm_j69/T/nvimfAJWz1/2')"]':
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/neovim/plugin/script_host.py", line 166, in python_eval
    return eval(expr, self.module.__dict__)
  File "<string>", line 1, in <module>
  File "/Users/lanza/Projects/nvim-gdb/lib/info_breakpoints.py", line 24, in InfoBreakpoints
    data, addr = sock.recvfrom(65536)
Press ENTER or type command to continue
Error detected while processing function <SNR>165_OnBufEnter[5]..<SNR>165_GdbPaused_info_breakpoints[27]..<SNR>165_InfoBreakpoints[5]..provider#python3#Call:
line   18:
socket.timeout: timed out
Press ENTER or type command to continue
Error detected while processing function <SNR>165_OnBufEnter[5]..<SNR>165_GdbPaused_info_breakpoints[29]..<SNR>165_RefreshBreakpointSigns[2]..<SNR>165_SetBreakpointSigns:
line    6:
E715: Dictionary required
Press ENTER or type command to continue
Error detected while processing function <SNR>165_OnBufEnter[5]..<SNR>165_GdbPaused_info_breakpoints[29]..<SNR>165_RefreshBreakpointSigns[2]..<SNR>165_SetBreakpointSigns:
line    6:
E714: List required
Press ENTER or type command to continue

Can it support for vim8 ?

It seems that there isn't a plugin that support lldb for vim8 now.
Will you develop this to support vim8 ?

Overwrite default mappings

How to overwrite the default mappings for <Leader>dd and <Leader>dl ?

I don't want to remove ./a.out all of the time.
This did not work

nnoremap <leader>dd :GdbStart gdb -q -f
nnoremap <leader>dl :GdbStartLLDB lldb

Interrupt in lldb

info line is called for gdb in the function nvimgdb#Interrupt(). Check it works in lldb too.

[lldb] first secondary channel idea - query stack

So as a first idea of a feature that can be implemented via lldb's python API would be to query for the stack. You can do this either with a :NvimGdbQueryStack or as a persistent display on every single stop.

This could be don via something like (making up the APIs as I go as I don't know them all off the top of my head)

if is_x86_64():
    stack_pointer = "$rsp"
else:
    stack_pointer = "$sp"
output = lldb.HandleCommand(f"memory read -l 8 -c 64 {stack_pointer}")
process_stack_output(output)
vim.command("vert bo 30new | setlocal notemp | setlocal readonly")
w = vim.windows.getlast()
w.contents = output

What are your thoughts on this?

Frequently hitting "breakpoint.lua:95: connect: No such file or directory"

Error detected while processing function <lambda>1:
line    1:
E5108: Error while calling lua chunk for luaeval(): ...g/nvim/pack/minpac/start/nvim-gdb/lua/gdb/breakpoint.lua:95: connect: No such file or directory

This happens frequently upon just launching lldb.

Seems like the UDS isn't being created at some point? Can't make sense out of the moonscript syntax to really follow it.

Two way socket communication with lldb

lldb has listeners and event emitters that will let you know when the state changes and events in the debugger. e.g. you can register to listen for StateChanged and check if StateStopped and StopReasonBreakpoint. This will fix the bt bug where nvim-gdb switches files 14 times for all 14 stack frames due to lldb printing out 14 frames and nvim-gdb parsing 14 different cues to switch files.

And obviously this opens up the possibilities for many other improvements once you get that going. (e.g. querying frame var after every stop and updating a side panel with the variable info, thread lists, frame lists, memory views, etc etc etc)

Here's a little example script that demonstrates the APIs:

https://github.com/apple/swift-lldb/blob/stable/examples/python/performance.py

Any interest on this idea?

Unknown function: GdbInit

Running GdbStart gdb produces the error:

Error detected while processing function nvimgdb#Spawn:
line    1:
E117: Unknown function: GdbInit

Catch lldb's breakpoint command to display them in source

If I'm in the source code and I press F8, I will see a breakpoint appear on the line.
If I'm in lldb and I type breakpoint set --file file.c --line X, I will not see the breakpoint appear on the line.

Will try to confirm on gdb as well when I can.
Btw, great plugin.

Python3 EvalWord

While using GdbStartPDB python3 ..., GdbEvalWord doesn't have knowledge that I'm using python 3, so it uses print ... instead of print(...)

module 'gdb.app' not found

After upgrading this morning I the plugin does not work. Instead much error text is generated centering around a missing gdb.app, eventually ending with:

E5108: Error while calling lua chunk for luaeval(): [string ""]:1: attempt to index global 'gdb' (a nil value)

I checked the prerequisites, but maybe I missed something. I can't seem to find this gdb.app lua module anywhere. Is it part of this plugin or something else? Any tips? It worked great before, and I love this plugin.

Using NVIM v0.3.1 from the 18.04LTS package from the Ubuntu repos.

Feature request: python virtualenvs

When providing the full python executable I would expect sys.path to be set as:

$ .venv/bin/python -m pdb foo.py
$ (Pdb) import sys
$ (Pdb) sys.path
['', '/Users/berserk/Source/ocean/.venv/lib/python36.zip', '/Users/berserk/Source/ocean/.venv/lib/python3.6', '/Users/berserk/Source/ocean/.venv/lib/python3.6/lib-dynload', '/nix/store/mb1fwxr8w1n16fww8bp8spy6xy5dbjhm-python3-3.6.6-env/lib/python3.6', '/Users/berserk/Source/ocean/.venv/lib/python3.6/site-packages']

Whereas in :exe 'GdbStartPDB '.expand('%:p:h').'/.venv/bin/python -m pdb '.expand('%'), sys.path is equal to that of $ python -m pdb foo.py.

Might be the cause of #42, since my virtualenv's python is 3 and my system's python is 2.

Avoid interrupting running programs

The plugin tends to issue <c-c> here and there for its own purposes. Try to leave the execution intact at all times. One way could be to defer the execution to the time when the program is interrupted by other events.

Fix PDB tests

Look at the TODOs in the test_30_pdb.py. Decide how to fix the disabled checks.

Query breakpoints from LLDB on every step

Consider querying for LLDB breakpoints on every step just like in GDB (#20). Unfortunately, LLDB doesn't allow concealing commands in the history. So need to scout anything useful in LLDB API.

Design automated tests

We'll need a C++ test project. Consider dependencies (gdb, lldb, cmake, shell). Investigate available vim/shell test frameworks.

Undefine commands after :GdbDebugStop

It looks like the commands like :GdbNext persist. They are useless after the debugging session.
Consider undefining them after quitting a session.

Clear breakpoint signs after :GdbDebugStop

Consider the scenario:

  • Start debugging <leader>dd
  • Open a source file
  • Set a breakpoint with <f8>
  • ...
  • End debugging :GdbDebugStop

The breakpoint marker stays on. Should be gone.

Unknown sign: GdbCurrentLine

Just rebased to check your current patch and hit this immediately. I went to the docs and copied in

      \ 'sign_current_line': '▶',
      \ 'sign_breakpoint': [ '●', '●²', '●³', '●⁴', '●⁵', '●⁶', '●⁷', '●⁸', '●⁹', '●ⁿ' ]
      \ }

to both my config and default config_override and it still errors out. Hackaround was just to sign define GdbCurrentLine text=▶ in my init.vim.

Consider supporting pdb

Python built-in debugger. Should be suitable for integration.
The goal is to keep the reference to the source code while debugging, to benefit from vim navigation when setting breakpoints.

LuaJIT: install.sh doesn't finish successfully " error loading module 'lfs' "

Hi, I was trying to use your plugin when I encountered several issues.
First of all, I think you should point out in your README.md that you have to launch ./install in the plugin directory to install it.
But then, when I tried, I got the following output at the end:

Installing https://luarocks.org/json-lua-0.1-3.rockspec

Cloning into 'json-lua'...
remote: Enumerating objects: 7, done.
remote: Counting objects: 100% (7/7), done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 7 (delta 0), reused 3 (delta 0), pack-reused 0
Receiving objects: 100% (7/7), 15.89 KiB | 15.89 MiB/s, done.
Do not use 'module' as a build type. Use 'builtin' instead.
json-lua 0.1-3 is now installed in /home/narice/.vim/bundle/nvim-gdb/lua/rocks (license: CC)

/usr/bin/luajit: ...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: error loading module 'lfs' from file '/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so':
	/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so: undefined symbol: luaL_setfuncs
stack traceback:
	[C]: in function 'a_loader'
	...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: in function <...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:150>
	[C]: in function 'require'
	...ocks/lib/luarocks/rocks-5.1/moonscript/0.5.0-1/bin/moonc:4: in main chunk
	[C]: at 0x563de9e87c00
/usr/bin/luajit: ...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: error loading module 'lfs' from file '/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so':
	/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so: undefined symbol: luaL_setfuncs
stack traceback:
	[C]: in function 'a_loader'
	...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: in function <...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:150>
	[C]: in function 'require'
	...ocks/lib/luarocks/rocks-5.1/moonscript/0.5.0-1/bin/moonc:4: in main chunk
	[C]: at 0x55b8eda61c00
/usr/bin/luajit: ...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: error loading module 'lfs' from file '/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so':
	/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so: undefined symbol: luaL_setfuncs
stack traceback:
	[C]: in function 'a_loader'
	...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: in function <...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:150>
	[C]: in function 'require'
	...ocks/lib/luarocks/rocks-5.1/moonscript/0.5.0-1/bin/moonc:4: in main chunk
	[C]: at 0x55734df2cc00
/usr/bin/luajit: ...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: error loading module 'lfs' from file '/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so':
	/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so: undefined symbol: luaL_setfuncs
stack traceback:
	[C]: in function 'a_loader'
	...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: in function <...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:150>
	[C]: in function 'require'
	...ocks/lib/luarocks/rocks-5.1/moonscript/0.5.0-1/bin/moonc:4: in main chunk
	[C]: at 0x55943d2cac00
/usr/bin/luajit: ...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: error loading module 'lfs' from file '/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so':
	/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so: undefined symbol: luaL_setfuncs
stack traceback:
	[C]: in function 'a_loader'
	...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: in function <...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:150>
	[C]: in function 'require'
	...ocks/lib/luarocks/rocks-5.1/moonscript/0.5.0-1/bin/moonc:4: in main chunk
	[C]: at 0x563afdcfac00
/usr/bin/luajit: ...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: error loading module 'lfs' from file '/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so':
	/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so: undefined symbol: luaL_setfuncs
stack traceback:
	[C]: in function 'a_loader'
	...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: in function <...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:150>
	[C]: in function 'require'
	...ocks/lib/luarocks/rocks-5.1/moonscript/0.5.0-1/bin/moonc:4: in main chunk
	[C]: at 0x5629926f6c00
/usr/bin/luajit: ...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: error loading module 'lfs' from file '/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so':
	/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so: undefined symbol: luaL_setfuncs
stack traceback:
	[C]: in function 'a_loader'
	...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: in function <...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:150>
	[C]: in function 'require'
	...ocks/lib/luarocks/rocks-5.1/moonscript/0.5.0-1/bin/moonc:4: in main chunk
	[C]: at 0x5595897b2c00
/usr/bin/luajit: ...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: error loading module 'lfs' from file '/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so':
	/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so: undefined symbol: luaL_setfuncs
stack traceback:
	[C]: in function 'a_loader'
	...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: in function <...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:150>
	[C]: in function 'require'
	...ocks/lib/luarocks/rocks-5.1/moonscript/0.5.0-1/bin/moonc:4: in main chunk
	[C]: at 0x56447d279c00
/usr/bin/luajit: ...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: error loading module 'lfs' from file '/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so':
	/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so: undefined symbol: luaL_setfuncs
stack traceback:
	[C]: in function 'a_loader'
	...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: in function <...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:150>
	[C]: in function 'require'
	...ocks/lib/luarocks/rocks-5.1/moonscript/0.5.0-1/bin/moonc:4: in main chunk
	[C]: at 0x557a76f05c00
/usr/bin/luajit: ...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: error loading module 'lfs' from file '/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so':
	/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so: undefined symbol: luaL_setfuncs
stack traceback:
	[C]: in function 'a_loader'
	...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: in function <...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:150>
	[C]: in function 'require'
	...ocks/lib/luarocks/rocks-5.1/moonscript/0.5.0-1/bin/moonc:4: in main chunk
	[C]: at 0x56284b54ac00
/usr/bin/luajit: ...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: error loading module 'lfs' from file '/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so':
	/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so: undefined symbol: luaL_setfuncs
stack traceback:
	[C]: in function 'a_loader'
	...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: in function <...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:150>
	[C]: in function 'require'
	...ocks/lib/luarocks/rocks-5.1/moonscript/0.5.0-1/bin/moonc:4: in main chunk
	[C]: at 0x564c56e84c00
/usr/bin/luajit: ...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: error loading module 'lfs' from file '/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so':
	/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so: undefined symbol: luaL_setfuncs
stack traceback:
	[C]: in function 'a_loader'
	...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: in function <...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:150>
	[C]: in function 'require'
	...ocks/lib/luarocks/rocks-5.1/moonscript/0.5.0-1/bin/moonc:4: in main chunk
	[C]: at 0x560705880c00

All the following errors seems to point to the same cause, the lfs module, but I don't really know what to do at this point.
I hope the output helps you a bit.

Thanks in advance!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.