Löve debugging with ZeroBrane Studio

[bartbes]

It seems like löve is using some sort of "strict" module, which I didn't realize.

It's not.
However, there is no jit module/variable, since it's running on lua, not luajit.

[paulclinger]

However, there is no jit module/variable, since it's running on lua, not luajit.

Right, but it is a general debugger that has specific handling for applications that run on luaJIT. I changed the check, so the message should only appear once per session.

[kclanc]

Type guessing was mentioned in the features list. By trapping errors, I mean allowing the user to examine the state of the program, in the stack view, after an error has occurred.

[paulclinger]

Type guessing was mentioned in the features list. By trapping errors, I mean allowing the user to examine the state of the program, in the stack view, after an error has occurred.

For the type guessing I think we meant the logic in this fragment (https://github.com/pkulchenko/ZeroBrane ... ec/lua.lua; check typeassigns method), but it's a bit underdeveloped. There is also type guessing in luainspect that I integrated for the static code analysis, but the type inspection is disabled by default, because it depends on code evaluation, which tends to be very slow even on medium size code files.

For the trapping, I don't wrap the code executed into pcall or xpcall and as such can't trap the errors; you still get the blue screen, but if you're debugging from the IDE, you get a stack trace in the output window, which you can navigate with double clicks. It's not much in terms of a help, but I want the debugging to be as non-invasive as possible and with as little change to your code as possible.

If you open the stack window (before the error), you will see whatever stack trace was observed last and can still see all the data in the stack (as it's captured as a snapshot), but the stack is only re-evaluated when the code is being stepped through or stopped at a breakpoint.

[Lap]

Hhmmmm...on adding the mobdebug line and trying to debug it through ZB Studio all I get is a forever frozen Love program screen with no output of any kind. No messages in the ZB output either so I really don't know where to go from here.

[kclanc]

For me, it was breaking on that line. You might just have to open up ZeroBrane and tell the debugger to continue. Also, did you comment out the line that I mentioned above?

[Lap]

For me, it was breaking on that line. You might just have to open up ZeroBrane and tell the debugger to continue. Also, did you comment out the line that I mentioned above?

Definitely was breaking there. Can't seem to get toggled breakpoints to actually break at all.

I also don't know if I'll be able to tolerate the speed decrease (0.1-2% of normal speed). That's a pretty brutal slow down and I don't remember Decoda having such issues.

[paulclinger]

Hi Lap,

There is no question Decoda is going to be faster as it works directly with the Lua state, whereas ZeroBrane Studio (or, more specifically, MobDebug) is using debug hooks, so it's called on every line. Using this method though gives it some advantages over Decoda (although speed is not one of them) .

In terms of making it a bit faster I've considered several options. First of all, only one thread that called "start" method is going to get its debug hook, so you can use coroutines to "hide" your code from the debugger, which will allow it to run with its normal speed. I don't expect you to wrap your code in coroutines just to make the debugging to go faster, but I used this methods in the debugger itself to implement socket functions on mobile devices (and avoid calling hooks on that code, which was making it really slow).

Another option is to add "stop" method, which will allow you to start/stop the debugger in your code, and as such limit the exposure and improve its performance. Obviously breakpoints and all other commands (like Break) will only work between those start/stop commands.

Yet another option is to stop on every Nth hook (rather than on every one), which will allow you to get proportionally faster (stopping on every 100th instead of on each one runs approximately 10-30 times faster). This functionality is already implemented, but has not been exposed in the API yet as it may be a bit confusing as some of the breakpoints may not work even when the execution seems to go through that fragment as the breakpoint condition doesn't get checked.

Based on my experience, the first two options are probably the best ones (I'll work on adding the "stop" method if I can get it to work with the IDE). If someone has other ideas, I'll definitely consider them.

Paul.

[bartbes]

It might be interesting to see if a dynamic step size could be implemented, i.e. set it to go 100 lines by default, but if it sees that there's a breakpoint coming up in 30, temporarily set it to less, so you can get there. Now, with calls and all this would be incredibly hard to get right, but even if it only works sometimes it might just be good enough for finding weak points.

In any case, being able to set the amount of times it stops would be a good option if implemented.

[Lap]

I second bartbes option, but any of those ideas would probably be a significant improvement.

On a separate note, it would also be nice to be able to take the "jump to function" drop down and optionally sort it alphabetically.