Re: Using debugging hooks as a 'watchdog' on code execution?
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: Using debugging hooks as a 'watchdog' on code execution?
- From: Stephen Kellett <lua@...>
- Date: 2008年1月04日 11:14:32 +0000
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