Re: Using debugging hooks as a 'watchdog' on code execution?

[Stephen Kellett <lua@...>]

Kurt Nordstrom wrote:
> My question is, primarily, is this a bad way to go about it?  

No. Its simple and it will work.

There may be other better, more complicated solutions (such as 
pre-processing the Lua code to put the checks in the Lua).

> The hooks
> are classified as being there for debugging purposes, and I'm essentially
> wanting to use them to create a sandbox.  Are there any problems or
> pitfalls to this approach that I should be aware of?  

Depends upon what you do in your debug hook. I seem to remember a few 
unexpected things when we worked with them. Unfortunately I can't 
remember what they were, but they were edge cases. Good chance you won't 
even bump into them.

>Would I be taking a
> significant performance hit with this sort of monitoring?

Not necessarily. Depending upon what you do in the callback it could be 
lightweight or have quite a penalty. You could do anything in that 
callback from incrementing a counter and comparing

	linesExecuted++;
	if (linesExecuted > tooManyLines)
		killCode();

to implementing a full blown flow tracer that grabs all parameters and 
locals, gets their string representations and then stores them. The 
latter has quite a performance hit (we have a flow tracer in beta test).

Based on what you describe, I'd expect your code to be at the lighter 
end of the two.

If you use Firefox and have ever run a lengthy JavaScript you will have 
seen a "this script is taking too long, do you wish to continue?" type 
of dialog. This warning dialog is done essentially using the same 
technique you are asking about here.

For Firefox their check is placed in the "branch execution" callback, 
which is not really a branch (as in go this way or that way) callback, 
but a callback that gets executed for every instruction executed.

The Firefox "too long" detection wasn't concerned about going through a 
particular point too often. Effectively it had a counter that was 
incremented with every instruction (or every line in your case) and when 
the count was exceeded you got asked the question. Answer Yes to 
continue and No to abort the script.

I'd recommend you give it a try. If it is too expensive for you, you can 
always do a timer based version (remember to turn the timer off during 
GUI interactions - they may be slow to click the OK button!).

Stephen