Nvim :help
pages, generated
from source
using the tree-sitter-vimdoc parser.
ulimit -c unlimited
coredumpctl -1 gdb
sudo apt install systemd-coredump
bt.txt
file:
2>&1 coredumpctl -1 gdb | tee -a bt.txt
thread apply all bt full
core
file will appear in the current directory. To get
a backtrace from the core
file:
gdb build/bin/nvim core 2>&1 | tee backtrace.txt
thread apply all bt full
nvim
crashes, you can see the backtrace in Console.app
(under "Crash
Reports" or "User Diagnostic Reports" for older macOS versions).
open -a Console
/cores/
directory exists and is writable:
sudo mkdir /cores
sudo chown root:admin /cores
sudo chmod 1775 /cores
unlimited
:
ulimit -c unlimited
~/.bashrc
or similar).
lldb
:
lldb -c /cores/core.12345
/etc/launchd.conf
).
TEST_TAG
to run tests matching busted tags (of the form #foo
e.g.
it("test #foo ...", ...)
):
GDB=1 TEST_TAG=foo make functionaltest
gdb build/bin/nvim
target remote localhost:7777
-- See nvim_argv
in https://github.com/neovim/neovim/blob/master/test/functional/testnvim.lua.
lldb .deps/usr/bin/luajit -- .deps/usr/bin/busted --lpath="./build/?.lua" test/unit/
nvim
process with a pid of 1234:
gdb -tui -p 1234 build/bin/nvim
gdb
interactive prompt will appear. At any time you can:
break foo
to set a breakpoint on the foo()
function
n
to step over the next statement
<Enter>
to repeat the last command
s
to step into the next statement
c
to continue
finish
to step out of the current function
p zub
to print the value of zub
bt
to see a backtrace (callstack) from the current location
CTRL-x CTRL-a
or tui enable
to show a TUI view of the source file in the
current debugging context. This can be extremely useful as it avoids the
need for a gdb "frontend".
<up>
and <down>
to scroll the source file view
set record full insn-number-max unlimited
continue
for a bit (at least until main()
is executed
record
revert-next
, reverse-step
, etc. to rewind the
debugger
gdb
clients to the same running nvim
process, or you may want to connect to a remote nvim
process with a local
gdb
. Using gdbserver
, you can attach to a single process and control it
from multiple gdb
clients.
gdbserver
attached to nvim
like this:
gdbserver :6666 build/bin/nvim 2> gdbserver.log
gdbserver
is now listening on port 6666. You then need to attach to this
debugging session in another terminal:
gdb build/bin/nvim
gdb
, you need to attach to the remote session:
target remote localhost:6666
signal (SIGTTOU, SIG_IGN); if (!tcsetpgrp(data->input.in_fd, getpid())) { perror("tcsetpgrp failed"); }
tui.c:terminfo_start
.
gdbserver
method mentioned above.
This example local.mk
will create the debugging session when you typemake
debug`.
.PHONY: dbg-start dbg-attach debug build
build:
@$(MAKE) nvim
dbg-start: build
@tmux new-window -n 'dbg-neovim' 'gdbserver :6666 ./build/bin/nvim -D'
dbg-attach:
@tmux new-window -n 'dbg-cgdb' 'cgdb -x gdb_start.sh ./build/bin/nvim'
debug: dbg-start dbg-attach
gdb_start.sh
includes gdb
commands to be called when the debugger
starts. It needs to attach to the server started by the dbg-start
rule. For
example:
target remote localhost:6666 br main