lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

----- Original Message -----
From: Paul K
Date: 2/14/2013 10:19 AM
In ZBT's case, it looks like the program being debugged needs to be modified
in order to be debugged by putting `require("mobdebug").start()` somewhere
near the start of the Lua code. In Decoda's case, absolutely zero
modifications are needed.
True; although as I understand you'd still need to have debugging
symbols for your executable available for Decoda, which means you may
need to recompile the project anyway.
One of the best features of this is that it (theoretically... I've never looked myself) would not cause any additional garbage to be created for Lua to collect. When you are working within constrained memory heaps, I want to debug my Lua code in the same state that it would ship in. Most remote debuggers like mobdebug end up loading additional stuff into the Lua state and causing additional memory usage.

There is another interesting theoretical Decoda feature that hooking the remote process may offer. (Again, I haven't looked at the code.) Decoda probably did not set up a line hook, as it wouldn't necessarily have rights to add executable code to your process. Line hooks are horribly slow; in fact, Adobe posted a patch on the mailing list for Lua 5.1 that added real breakpoints and allowed the Lua code to run at full speed otherwise. If they are just monitoring the Lua state from the Decoda process, then the Lua state can run at 'full' speed.

I look forward to perusing their source code soon.