From a Lua author’s point of view the debugger is a thin layer around a single Lua feature — a line hook — plus a UI that knows how to inspect the Lua stack while that hook is stopped at a line:
Your Lua script
|
v
+---------------+ on every line:
| Lua VM | --- is this line a breakpoint
+-------+-------+ or the next step target?
| |
| run | pause
v v
(next Lua line) +---------------------+
| Debugger dialog |
| Stack / Variables |
| Watch / Evaluate |
+----------+----------+
|
| Continue / Step
v
(back to Lua VM)
While the debugger is Enabled, a line hook (the same mechanism
debug.sethook exposes to Lua) runs before every line of Lua
code and checks the current source and line against the
breakpoint list and any pending step target. Until a hit, scripts
run at full speed; the hook has no effect on dissector output.
When the hook decides to pause, your Lua code is frozen mid-line. The rest of Wireshark cannot dissect packets, run taps, or call any other Lua code until you resume — that is why the main window grays out and why live capture is not compatible with pausing (see Section 14.2.1, “Live-capture suppression”).
Everything shown in the Variables tree, Watch tree, and Stack Trace
is read directly from the paused Lua state through the standard
Lua reflection surface — debug.getlocal, debug.getupvalue,
and the Globals environment as described in
Section 14.5, “Variables”. Reload Lua Plugins in the toolbar
re-runs the full plugin load sequence in a fresh VM (see
Section 14.4, “Toolbar”); debugger state — breakpoints,
watches, open editor tabs, and the current theme — survives the
reload, anything the script stashed in globals does not.