Zengtudor/ccls
1
0
Fork 0
mirror of https://github.com/MaskRay/ccls.git synced 2024-11-22 15:45:08 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Debugging update

Paul Smith 2019-01-02 00:41:04 -05:00 committed by Fangrui Song
parent 021bf49869
commit 7d3331477a
1 changed files with 35 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

55
Debugging.md

@ -1,24 +1,25 @@
First of all, use a Debug [[Build]]. It is compiled with `-O0 -g` while the default Release is `-O3`. First of all, use a [`Debug` build](Build#cmake-options). It is compiled with
`-O0 -g` while the default `Release` build is `-O3`.
### Logs ### Logs
`-log-file=/tmp/cc.log -v=1` Enable [logging](Customization#--log-filefile----log-file-appendfile) and
[verbose](Customization#-vn) mode when starting the server.
`-v=1` dumps command line options used for parsing.
### stderr ### stderr
You can find stderr output in: You can find stderr output in:
* LanguageClient-neovim: `/tmp/LanguageServer.log` (default) * [[LanguageClient-neovim]]: `/tmp/LanguageServer.log` (default)
* Emacs lsp-mode: `*lsp-ccls stderr*` buffer. They will also go to `*message*` buffer if `(setq lsp-print-io t)` * Emacs [[lsp-mode]]: `*lsp-ccls stderr*` buffer. They will also go to
`*message*` buffer if `(setq lsp-print-io t)`
* VSCode: TODO * VSCode: TODO
### Dump LSP requests/responses ### Dump LSP requests/responses
On Linux: On Linux:
```zsh ```sh
# sysdig # sysdig
sudo sysdig -As999 --unbuffered -p '%evt.type %proc.name %evt.buffer' "proc.exe contains ccls and fd.type=pipe" | egrep -v '^Content|^$' sudo sysdig -As999 --unbuffered -p '%evt.type %proc.name %evt.buffer' "proc.exe contains ccls and fd.type=pipe" | egrep -v '^Content|^$'
@ -28,42 +29,56 @@ strace -s999 -e read,write -fp $(pgrep -fn ccls)
### Stopping at the start to debug early issues ### Stopping at the start to debug early issues
To debug individual LSP requests, you can attach your debugger after ccls has done indexing. However, To debug individual LSP requests, you can attach your debugger after ccls has
for many other issues, such as project file loading (`project.cc`) and C/C++ parsing and indexing `indexer.cc`, you need to set an early breakpoint to be able to trace the code. done indexing. However, for many other issues, such as project file loading
(`project.cc`) and C/C++ parsing and indexing `indexer.cc`, you need to set an
early breakpoint to be able to trace the code.
It is recommended to use [[LanguageClient-neovim]] for debugging (even if you use Emacs or VSCode) because it can be started with simple shell command. It is simplest to use [[LC-neovim]] for debugging (even if you use Emacs or
VSCode) because it can be started with simple shell command.
```vim ```vim
# vimrc # vimrc
nn ,al :LanguageClientStart<cr> nn ,al :LanguageClientStart<cr>
``` ```
```zsh ```sh
rm -r /tmp/ccls && CCLS_TRACEME=1 nvim a.cc +'normal ,al' rm -r /tmp/ccls && CCLS_TRACEME=1 nvim a.cc +'normal ,al'
``` ```
The Neovim buffer will hang there because `CCLS_TRACEME=1` causes the `ccls` process to SIGTSTP itself. In another shell, `gdb -p $(pgrep -fn debug/ccls)` The Neovim buffer will hang there because `CCLS_TRACEME=1` causes the `ccls`
process to SIGTSTP itself. In another shell, `gdb -p $(pgrep -fn debug/ccls)`
### Poor man's breakpoint ### Poor man's breakpoint
Insert an infinite loop `volatile static int z=0;while(!z);` somewhere and ccls will stop there. Attach to the ccls process with `gdb -p $(pgrep -fn ccls)`. Set some breakpoints, use `print` commands, and execute `p z=1` for continuing. Insert an infinite loop `volatile static int z=0;while(!z);` somewhere and
ccls will stop there. Attach to the ccls process with `gdb -p $(pgrep -fn
ccls)`. Set some breakpoints, use `print` commands, and execute `p z=1` for
continuing.
When setting breakpoints, if several threads may stop on the same breakpoint (e.g. concurrent indexer threads), When setting breakpoints, if several threads may stop on the same breakpoint
execute `set scheduler-locking on`. (e.g. concurrent indexer threads), execute `set scheduler-locking on`.
### Using a debugger ### Using a debugger
Cache files are deleted to avoid possible issues related to stale cache. `CCLS_TRACEME=1` causes the ccls process to stop at the start of `main()`. You may attach to the process with: Cache files are deleted to avoid possible issues related to stale
cache. `CCLS_TRACEME=1` causes the ccls process to stop at the start of
`main()`. You may attach to the process with:
Use `CCLS_TRACEME=s` to `raise(SIGSTOP)`, if `SIGTSTP` does not work. Use `CCLS_TRACEME=s` to `raise(SIGSTOP)`, if `SIGTSTP` does not work.
* `gdb -p $(pgrep -fn ccls)`. Invoke `signal SIGCONT` if you want ccls to continue running after detaching of gdb. * `gdb -p $(pgrep -fn ccls)`. Invoke `signal SIGCONT` if you want ccls to
* `lldb -p $(pgrep -fn ccls)`. Invoke `pro sig SIGCONT` when the process resumes (with a `c` command) if you want ccls to continue running after detaching. continue running after detaching of gdb.
* `lldb -p $(pgrep -fn ccls)`. Invoke `pro sig SIGCONT` when the process
resumes (with a `c` command) if you want ccls to continue running after
detaching.
### Indexer issues ### Indexer issues
`export CCLS_CRASH_RECOVERY=0` disables clang crash recovery. In case of clangIndex issues, you will not see `clang crashed` in the log file but get a process crash. And if you attach a debugger before it crashes, you can get the stack trace. `export CCLS_CRASH_RECOVERY=0` disables clang crash recovery. In case of
clangIndex issues, you will not see `clang crashed` in the log file but get a
process crash. And if you attach a debugger before it crashes, you can get the
stack trace.
## Developing ## Developing