14.13. Troubleshooting
Prev | Chapter 14. Lua Debugger | Next

## 14.13. Troubleshooting

The debugger never pauses. Check that Enabled is ticked and that you are not in a live capture — the debugger is forcibly disabled while live capture is running (see Section 14.2.1, “Live-capture suppression”). Check that the breakpoint file path matches the path the Lua loader actually used. A file opened via a symlink can end up with a different path than the loaded copy — in that case open the script from the Files tree (which always uses the loader’s path) and set the breakpoint from there.

Watch row shows red with "Path not found". The spec is a valid watch path but did not resolve in the current scope. If the spec is unqualified, try `Locals.`, `Upvalues.`, or `Globals.` explicitly to see which section the symbol is actually in. For scripts loaded via `dofile` whose globals live in `_ENV`, prefer `Globals.name` over a bare name.

Watch row shows red with a Lua error message. The row is an expression watch (its tooltip says Expression — re-evaluated on every pause.) and either failed to compile or raised at runtime; the row’s text is the verbatim Lua error. The usual suspects are:

- `attempt to index a nil value` — a name on the path is `nil` at this pause. Confirm it with a path watch on the same name, or use the Evaluate panel.
- `attempt to perform arithmetic on a <kind> value` — an operator received the wrong type; check with `type(…​)` first.
- `'<eof>' expected` or `'=' expected near …` — the expression doesn’t parse. A common cause is putting a statement (an assignment, `if`, `for`, `local`) in the Watch column; use the Evaluate panel for those.
- A user-supplied message after `assert` or `error` — a predicate watch fired (see Predicates and "tell me when X changes" in Section 14.6.3, “Expression patterns”).

Evaluate reports "attempt to index a nil value". The paused expression tried to dereference a field that is `nil` at this pause. Use the Variables tree or a broader root expression to confirm what is (and is not) bound at the pause point.

Changed-value cue cleared across a call/return. This is by design — see Section 14.5.1, “Changed-value cue”. The cue resumes on the next pause inside the original function.

The main window refuses to close while paused. Resume (Continue) or Step first, then close. Close requests targeted at the main window or `Ctrl+Q` while the debugger is paused are deferred and re-delivered automatically once the pause ends, so Wireshark never tries to shut down with Lua code still on the stack. A shutdown request that arrived while a debugger editor tab has unsaved changes runs the same save/discard/cancel flow as closing the dialog before the shutdown can proceed.

Prev | Up | Next
14.12. Architecture | Home | Chapter 15. User Interface