Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to debug Lua remotely?

I'm searching for the best way to debug Lua remotely, ( like from a web browser ).

I saw RemDebug, but the last project update was done on 2006. It works with Lua 5.0 and 5.1, but Lua 5.2 is quite close, and I don't see RemDebug to get an update anytime soon.

I could mount a small embedded web-server on my debug host, and use something like RemDebug to communicate with it, and perform remote debugging via HTTP.

Suggestions are appreciated.

like image 692
Goles Avatar asked Mar 25 '11 22:03

Goles


1 Answers

I have developed a new debugger based on RemDebug (MobDebug) with new commands, new features, bugfixes, and integration with IDEs.

MobDebug is based on TCP interaction between the client (debugee) and the server (controller). This is also the case for RemDebug and most other remote debuggers. You might be able to run on top of something else (like WebSockets or HTTP), but you still need to be able to run coroutines and debug hook to control the application being debugged.

The architecture of the debugging process is quite simple:

  • You have an application you want to debug
  • You also have your debugger with a controller
  • The application loads the client components of the debugger, which opens a connection to the controller
  • The controller accepts commands from a command line or an IDE (MobDebug provides both; it integrates with ZeroBraneStudio and also provides a scriptable way to run it)
  • When the application is loaded, the debugger installs a debug hook, which is run on every line/call/return. From this debug hook a resume call is made to the debugger, which can then execute commands from the controller (like install a breakpoint, evaluate an expression and so on). When the next executable command is send (like run or step), the debugger yields back to the hook, which then returns back to the app allowing it to proceed.

It may be possible to mimic the existing socket interface (as it's only using connect/send/receive and select/timeout to abort the application) and reuse most of the library. I'm still not sure why you'd want to run this in a browser though as you can run the application on anything that supports TCP already (I have a working prototype debugging an application running on a mobile device from my desktop).

like image 121
Paul Kulchenko Avatar answered Oct 22 '22 07:10

Paul Kulchenko