Debugging Support for Lua

[atom]

I was able to load the OS module here on Ctrlr/Linux but this might behave differently on different OSes, hence the name.

I need to test it on Windows @home later.

[synth]

So it seems that I need to open the mobdebug.lua file in Ctrlr as well as my Test.lua file. Then I need to switch my project directory in Zerobrane to the one which has Test.lua

Then I need to choose save and compile all in Ctrlr which seems to notify Zerobrane. At least I can see that the code breaks there during compilation at :

require('mobdebug').start()

function testme()                    <----------------------- right here
    console("testme() called")
    console("Step 1")
    console("Step 2") 
end

Then I press F10 multiple times to complete the compilation. After that if I call testme() from the console, the code breaks at “console(“testme() called”)”

[synth]

I was able to load the OS module here on Ctrlr/Linux but this might behave differently on different OSes, hence the name.

Cool 🙂

• This reply was modified 9 years, 6 months ago by synth.

[synth]

So it seems that the lua callbacks for various events in a panel, they seem to be placed in the panel file itself. That makes them impossible to debug thorough an external debugger.

Maybe while creating a new method for one of the panel callbacks, there can be an option to add it to a .lua file. If the file does not exist its created. The method code is always compiled from this file and the file can be given to an external debugger while debugging.

By the way the socket library needs to be exposed by a call to CtrlrLuaSocket::wrapForLua(L) in CtrlrLuaManager::wrapCtrlrClasses(lua_State* L)

• This reply was modified 9 years, 6 months ago by synth.

[cyber.cbm]

Nice work I think it can help lot if panel has lot details in Lua. But with this changes I think we need proper management of lua files and functions inside files in lua Editor.

THanks.

[synth]

Looking at this more closely, it seems that what mobdebug does in Lua we can directly do in C++ through the Lua C API : http://www.lua.org/manual/5.1/index.html#index

MobDebug registers a debug_hook() in Lua and we can register a C function through : http://www.lua.org/manual/5.1/manual.html#lua_Hook

That would allow us to have a debugger integrated into Ctrlr itself rather then rely on an external debugger server.

We can also examine variable values and put them in a watch window and show the current stack : http://www.lua.org/manual/5.1/manual.html#lua_Debug

• This reply was modified 9 years, 6 months ago by synth.

[atom]

Yes this is exactly what i want to achieve at some point, give some basic debugging functionality inside Ctrlr so no external programs are needed and you can at least set breakpoints and see a stack-trace.

[synth]

I see you got started with an initial debugging facility in debugger.lua

I havent checked the implementation yet, but do you essentially put a debug hook that gets called before a line is executed by the Lua interpretor ?

I was wondering how a watch window and a stack trace window can be implemented. While the debugger is halted inside the debug hook, the main thread is blocked there ? Since this is the JUCE message thread, so that too is blocked ? So would it be possible to update a UI element in the Lua Method Editor with the values of watch variables and stack traces and see them appear ?

[atom]

The idea is, that when a breakpoint is hit (right now it’s a call to the dbg() method) a modal window will appear that blocks the main loop with a small interface to the debugger (things like, step, step-over, continue, stack-track, local-vars etc) and some kind of preview of the code that we are stepping over (if possible), once either “Continue” is selected or the debugger finishes, the window closes and the program continues.

[synth]

That sounds good for now 🙂

What would be really awesome to try, and is also a lot more complex, is to update the Method Editor window itself with an arrow pointing out the current line of execution. And have buttons there to control resuming, stopping, setting breakpoints etc. Currently we cannot do that because the lua code executes in the main thread and updates the lua state there. So if I write an infinite loop in a Lua method, the only way to stop it would be to shut down Ctrlr 😛

So we need to move the panel execution to its own thread. So a panel can be debugged. And a misbehaving panel cannot crash the editor itself. Just like browsers do with various tabs.

But I think we can have only one other thread and only one panel executing at any time to prevent 2 threads calling into C++ code via the lua bindings and causing race conditions and other threading conditions.

So the run_code method() always executes in a separate asynchronous task and the main thread simply disables the panel UI and the method editor UI and also the console :P. This way we prevent the lua state from being accessed from 2 threads and being corrupted.

When run_code() finishes in the async task we get a callback. If run_code() causes the debug function to be called, this function needs to communicate

the current line of execution
the current stack and
the values of watched variables

to the main thread.

• This reply was modified 9 years, 6 months ago by synth.
• This reply was modified 9 years, 6 months ago by synth.
• This reply was modified 9 years, 6 months ago by synth.

[synth]

On thinking more about this before I try this out, there is no need for a separate thread at all to update the Method Editor. The lua code can simply call back to C++ and there we can update the Method Editor and only show an UI to resume execution in a separate thread. Then we go into a modal loop in the main thread to block it.

When the user clicks resume, this separate thread terminates and unblocks the main thread to resume.

[paulclinger]

synth wrote:

require(‘mobdebug’).start()

function testme() <----------------------- right here console("testme() called") console("Step 1") console("Step 2") end[/quote] @synth, if I may offer a suggestion: you don't need to run start() at the beginning of the script if it interferes with your compilation. You can run it at any point and it will start the debugging correctly. It seems like in this case you can simply move it inside testme() function and the debugging will start only when you call testme from the console. > So it seems that I need to open the mobdebug.lua file in Ctrlr as well as my Test.lua file. Then I need to switch my project directory in Zerobrane to the one which has Test.lua

This may be fixed by moving the start() call into the testme() function as well. You’d only need to set the project directory to whatever directory this file you are debugging is in.

Also, I don’t expect you’d need to make changes to mobdebug as requiring “os” is behind pcall; this was done specifically to support the environments that may not have “os” module at all. Was it not working for you?

There is one more call that may help in your case. Since start() sets a debug hook and the hook is not removed until the debugging is done, it may interfere with some other Lua code you have in your framework. You can temporarily disable debugging using on()/off() calls or completely stop the debugging using done() call. So, in the case above:

function testme()
require(‘mobdebug’).start() —<-- start debugging console("testme() called") console("Step 1") console("Step 2") require('mobdebug').done() --<-- stop/complete debugging end Obviously breakpoints and stepping will only work while the debugging is enabled. Let me know if you can't get it to work and I'll try to help. Paul.

[atom]

There is an initial debugger implementation in 5.3 and up version of Ctrlr. To trigger a breakpoint in your code call pause(“message”) somewhere and it should eneter the debugger. I’m still working on it (doing local variable display, finding out types of variables, finishing up the stack trace, listing global variables).

[synth]

@paulclinger Yeah I realized that later that and removed the require mobdebug line from code. I was able to start debugging at any time and saw the code break in Zerobrane. I wasnt able to detach the debugger though. I think I tried require(‘mobdebug’).done() but it was crashing Ctrlr. I ll try it out once more and let you know. 🙂

Thanks for looking at this.

Atom,
Which library do you currently use for the debugger ?

[atom]

There is nothing on the C++ side, the debugging interface is already in lua (it was always there). In lua I use clidebugger, a non-remote version of RemDebug https://github.com/ToddWegner/clidebugger

[paulclinger]

synth wrote:

I was able to start debugging at any time and saw the code break in Zerobrane. I wasnt able to detach the debugger though. I think I tried require(‘mobdebug’).done() but it was crashing Ctrlr. I ll try it out once more and let you know.

If detaching still doesn’t work, you may try with MobDebug from 0.90 version of ZBS (should be v. 0.607+). There were some fixes for detaching that may help in your case as well.

Paul.

[atom]

I just wanted to say, that remote debugging will not work above version 5.3.0 because i removed the LuaSocket code from Ctrlr. I just don’t need it anymore with my local debugging code, but if you insist on that to work i can bring it back.

[Author]

Posts