diff options
| -rw-r--r-- | runtime/doc/dev_tools.txt | 61 |
1 files changed, 33 insertions, 28 deletions
diff --git a/runtime/doc/dev_tools.txt b/runtime/doc/dev_tools.txt index b9e1e68dbb..52513db31d 100644 --- a/runtime/doc/dev_tools.txt +++ b/runtime/doc/dev_tools.txt @@ -14,10 +14,10 @@ itself. See also |debug.txt| for advice that applies to Vim. ============================================================================== Backtraces *dev-tools-backtrace* -LINUX ~ +LINUX -Core dumps are disabled by default on Ubuntu -https://stackoverflow.com/a/18368068, CentOS and others. To enable core dumps: +Core dumps are disabled by default on Ubuntu, CentOS and others. +To enable core dumps: >bash ulimit -c unlimited < @@ -25,21 +25,29 @@ On systemd-based systems getting a backtrace is as easy as: >bash coredumpctl -1 gdb < -It's an optional tool, so you may need to install it: +`coredumpctl` is an optional tool, so you may need to install it: >bash sudo apt install systemd-coredump < -The full backtrace is most useful, send us the `bt.txt` file: +The full backtrace is most useful; please send us the `backtrace.txt` file +when reporting a bug related to a crash: >bash - 2>&1 coredumpctl -1 gdb | tee -a bt.txt - thread apply all bt full + 2>&1 coredumpctl -1 gdb | tee -a backtrace.txt + (gdb) thread apply all bt full < -On older systems a `core` file will appear in the current directory. To get -a backtrace from the `core` file: + +On systems without `coredumpctl`, you may find a `core` dump file appearing +in the current directory or in other locations. On Linux systems where +`apport` is installed (such as Ubuntu), the directory where core dump files +are saved can be `/var/lib/apport/coredump` or elsewhere, depending on the +system configuration (see `/proc/sys/kernel/core_pattern`). See also: +https://stackoverflow.com/a/18368068 + +To get a backtrace from the `./core` dump file: >bash - gdb build/bin/nvim core 2>&1 | tee backtrace.txt - thread apply all bt full + gdb build/bin/nvim ./core 2>&1 | tee backtrace.txt + (gdb) thread apply all bt full < MACOS @@ -76,7 +84,7 @@ core dumps with `/etc/launchd.conf`). ============================================================================== Gdb *dev-tools-gdb* -USING GDB TO STEP THROUGH FUNCTIONAL TESTS ~ +USING GDB TO STEP THROUGH FUNCTIONAL TESTS Use `TEST_TAG` to run tests matching busted tags (of the form `#foo` e.g. `it("test #foo ...", ...)`): @@ -86,19 +94,19 @@ Use `TEST_TAG` to run tests matching busted tags (of the form `#foo` e.g. Then, in another terminal: >bash gdb build/bin/nvim - target remote localhost:7777 + (gdb) target remote localhost:7777 -- See `nvim_argv` in https://github.com/neovim/neovim/blob/master/test/functional/testnvim.lua. -USING LLDB TO STEP THROUGH UNIT TESTS ~ +USING LLDB TO STEP THROUGH UNIT TESTS ->bash +> lldb .deps/usr/bin/luajit -- .deps/usr/bin/busted --lpath="./build/?.lua" test/unit/ < +USING GDB -USING GDB ~ - -To attach to a running `nvim` process with a pid of 1234: +To attach to a running `nvim` process with a pid of 1234 (Tip: the pid of a +running Nvim instance can be obtained by calling |getpid()|), for instance: >bash gdb -tui -p 1234 build/bin/nvim < @@ -117,8 +125,7 @@ The `gdb` interactive prompt will appear. At any time you can: need for a gdb "frontend". - `<up>` and `<down>` to scroll the source file view - -GDB "REVERSE DEBUGGING" ~ +GDB REVERSE DEBUGGING - `set record full insn-number-max unlimited` - `continue` for a bit (at least until `main()` is executed @@ -126,8 +133,7 @@ GDB "REVERSE DEBUGGING" ~ - provoke the bug, then use `revert-next`, `reverse-step`, etc. to rewind the debugger - -USING GDBSERVER ~ +USING GDBSERVER You may want to connect multiple `gdb` clients to the same running `nvim` process, or you may want to connect to a remote `nvim` process with a local @@ -145,12 +151,12 @@ debugging session in another terminal: < Once you've entered `gdb`, you need to attach to the remote session: > - target remote localhost:6666 + (gdb) target remote localhost:6666 < In case gdbserver puts the TUI as a background process, the TUI can become unable to read input from pty (and receives SIGTTIN signal) and/or output data (SIGTTOU signal). To force the TUI as the foreground process, you can add -> +>c signal (SIGTTOU, SIG_IGN); if (!tcsetpgrp(data->input.in_fd, getpid())) { perror("tcsetpgrp failed"); @@ -158,8 +164,7 @@ unable to read input from pty (and receives SIGTTIN signal) and/or output data < to `tui.c:terminfo_start`. - -USING GDBSERVER IN TMUX ~ +USING GDBSERVER IN TMUX Consider using a custom makefile https://github.com/neovim/neovim/blob/master/BUILD.md#custom-makefile to @@ -184,8 +189,8 @@ Here `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 + (gdb) target remote localhost:6666 + (gdb) br main < vim:tw=78:ts=8:et:ft=help:norl: |