Reading logs

The Logs panel — Ctrl+L — is the primary diagnostic tool. This page is about turning what it shows into a diagnosis.

Turn categories on in this order

Start narrow and widen only as needed.

1. Session — phase changes, adapter start and death, refused DAP requests. Most problems are named here outright, in one line.

2. Adapter — the adapter's own stderr. Language-specific complaints appear here: a missing Python module, a Go version mismatch, a missing shared library.

3. Program — your program's stdout and stderr. Useful for confirming the program ran at all, and how far it got.

4. DAP — the full request trace. Off by default because it is the noisiest.

Records are collected even while a category is off

You can enable DAP after something went wrong and still see what happened. There is no need to reproduce the failure with tracing on.

Reading the timeline

Timestamps are relative to the start of the session — +MM:SS.mmm — and restart after the ── new session ── separator.

Relative time answers the question you actually have while staring at a stuck debugger: how long has this been hanging?

A healthy start looks roughly like this:

+00:00.010 SESSION session starting, profile "api"
+00:00.050 SESSION building
+00:02.100 SESSION adapter dlv started (pid 43912)
+00:02.300 SESSION launch
+00:02.900 SESSION stopped at cmd/api/main.go:42

Whichever line is missing tells you where to look:

Last line seen	The problem lies in
session starting	the config or the profile
building	the compiler
adapter started	the adapter's own startup
launch	the request body or the program

A long request announces itself

Every 30 seconds, an unanswered request is noted:

+00:30.001 SESSION request `launch` running 30 s (mode=debug, program=/repo/cmd/api):
                   dlv (pid 43912) has not answered yet; timeout in 90 s

Everything needed for a decision is in that line: how long it has waited, how long remains, and which process is holding the answer. The pid makes it visible in ps:

ps -p 43912 -o pid,stat,etime,command

If it is busy compiling, waiting is right — or better, take the build out of the session; see Configuration → Profiles. If it is idle, the adapter is stuck and the answer is not going to come.

Buffer, copying and saving

The feed keeps the last 20 000 records.

Action	What it does
Copy	copies what is visible, respecting the filters
Save	writes the whole buffer, ignoring the filters, to <project>/.bugsaur/logs/<unix-ms>.log

Always use Save when reporting a problem. Filters that hid the cause from you would hide it from whoever reads the report.

Scrolling

The feed follows its tail. G turns following off so you can read without being dragged along; Shift+G turns it back on and jumps to the end.

Secrets are never in the log

Values of env do not appear — DAP request bodies are not printed. This is an invariant, not an accident: request tracing cannot be extended without stripping env values first. That is also why a long-request message includes only mode and program.

So a saved log is safe to attach to an issue, as far as env is concerned. It does still contain your paths, profile names and program output — glance through before posting.

What to attach to a bug report

1. The saved log file — the whole buffer.
2. The relevant profile from .bugsaur/config.toml.
3. The adapter version:

dlv version
codelldb --version
python3 -m debugpy --version

1. What you expected and what happened instead.