DDT3 Lua Debugger

DDT3 is a remote debugger for the Lua language, made of two components:

stand-alone client application with user interface - running on development PC
minimal, headless remote component - embedded in debuggee on target device, hooked into Lua runtime

communication happens over TCP/IP.

In motion

Differentiators

lightweight, low-level, stealthy daemon
written in ISO C++14, i.e. a debugger for Lua - not in Lua
no extraneous dependencies, no VM contamination, no Heisenbugs
supports LuaJIT 2.1 alpha/trunk and stock Lua 5.1 and 5.2
daemon loads scripts from memory, doesn't use filesystem
modular - integrate its code base into your in-house tools
trivial C++ host application integration; DDT binder is "just a C++ class"
binary network protocol using ASIO non-Boost
ABI-compatible with binary Lua modules and sister scripts (lua-socket, lua-sec, lua-posix, etc.)
async user log marshalling to client UI
debug directly from Win to iOS, without OSX bridge
supports command-line/shell scripts with colored stderr log
memory footprint typically under 100 KB
Valgrind-proofed
Unit-Tested

Platforms

Windows 7+
Mac OSX 10+
Apple iOS 8 including simulator
Linux kernel 3.x with Gtk 2/3

Client

step-by-step execution using line or instruction ticks, step in / over / out, run, break into debugger, inline breakpoint() function
load-break flag stops VM early when entering parse phase
breakpoints are fast - typically one bool* look-up per hook invocation
local, global and watch variables with table hierarchies including cycles, highlight changed var, auto-sort (promote recently changed), metatable detection, coroutine state, hyperlinked functions
rich variable scopes: local, global, upvalue, enval (_ENV-resident but outside _G), fixed and vararg function parameters (arguments), registry
type filtering: boolean, number, string, table, Lua function, thread/coroutine, metatable, userdata, C function, temporary, built-ins, registry
stack view with depth, call arguments, source filename:line and function name(s) incl. pluri-named and anonymous functions
memory inspector with canonical hex and ASCII views for large/multi-line strings and buffers with non-printable characters (incl. embedded zeroes), or loadstring()-contained Lua chunks. Updated in real-time
color-coded debug log with Visual Studio output
Lua files can be stored anywhere in client space (HDD, LAN)

UI navigation

location bookmarks with MRU recycling
drag & drop where possible: add Lua file(s) to project
show files in Explorer/Finder/Thunar
move & dispatch view panes into different notebooks
mouse-over variable resolution, CTRL-add to watches
hyperlink-based variable navigation

Script editor

based on Scintilla, with lexer and goodies
real-time text search with separate output pane
search toggles for case-sensitivity, whole-word, wildcard, regex, comment-skip, all project files, highlight
user bookmarks
lexer-extracted Lua functions pane
auto locks/unlocks files on debug session start/stop

Networking

ASIO-based, non-Boost flavor
non-blocking, stream-based, binary TCP protocol
logging facility queues daemon-side messages with preserved timestamps, routes them to the client efficiently (above screencast rewires Lua print() f.ex.)
stress-tests to detect faulty hardware (procedural echo)
can reloop daemon on script edit or error for back-to-back runs
client UI stays responsive with asynchronous I/O; daemon doesn't need it (nor should it consume extra threads)

headless waiting

Technologies

ISO C++14
Lua 5.2.3 and LuaJIT 2.1.0a (on daemon)
wxWidgets 3 (on client)
ASIO non-Boost version 1.10.3 / trunk
LLVM Clang++ 3.6 (trunk) on OSX and Linux
on Linux, Clang runs both libstdc++/GDB as well as libc++/LLDB with PathScale's libcxxrt
MSVC++ 2013, Clang, GNU g++ 4.7+ compilers on rotation
Valgrind
Catch Unit Testing

console debugging

FAQ

Q: What does your ISO C++ embrace mean practically?

A: The code is overwhelmingly platform- and toolkit-agnostic. It uses std::string, std::uint32_t, std::unordered_map and set, STL iterators, algorithms, etc. When interfacing with non-ISO code DDT dips its toe in and out as briefly as possible.

F.ex. DDT has its own logging facility using a light sig/slot pattern and a type-safe C++14 vararg template to mimic sprintf().

Q: We use QT/.Net/JUCE/other, not wxWidgets, is this a show-stopper?

A: No. DDT's UI widgets are portable by rendering to cairo 2D surfaces. Those can be Qt, OpenGL or any other available cairo backend.

The variable view pane (for locals, globals and watches) already uses this new model. Table hierarchies, mouse picking and hyperlinks are handled by DDT's own code. The editor is a straight Scintilla wrapper; lexing, highlighting, etc. are handled internally. The daemon is headless, so no UI issue there.

These new widgets are meant to fit with C++17's planned cairo integration.

Q: What's special about the networking layer?

A: Many know about Boost.Asio, few know its recent non-Boost flavor, which uses C++11 instead. It's just as fast, portable and still header-only but without Boost's baggage.

Asio was accepted in its entirety to form part of the next networking TS. See this C++ ISO report as well as think-async.com for technical details.

DDT uses binary TCP streams whose data is both platform- and arch- agnostic. F.ex. a Windows client connects directly to an iOS daemon - without OSX bridge.

Q: What does "DDT" stand for?

A: It's a punacronym for dedetizador which means "pest control" in Brazilian Portuguese (where Lua's from). Formally, "debugger" translates to "depurador".

Contact

email me for any questions, requests for references or otherwise.

i.e. [my first name] at [this domain]

fineprint:
- DDT3 is a proprietary evolution of DDT v0.92b which Inhance Digital Corporation open-sourced under MIT license on Feb 18, 2008 (all versions written by moi )
- some icons use placeholder art that may be under various licenses