Re: Partial solution to debugging eval() code

John J. Barton wrote:
> Unfortunately the key use case for this code is dojo, and for that the
> implementation is not quite enough.  As far as I can tell, dojo calls 
> eval() from eval() code. Errors in the second eval() will, in my scheme,
> be within the jsdIStackFrame.eval() call.  Code below this call seems to 
> be "undebuggable", that I cannot breakpoint it etc.
> 
> The question is why?  I cannot see from the spidermonkey or jsd code why
> this eval will not act like normal eval.  I do see a number of flags 
> that indicate that it is *intended* to be different (eg 
> JSFRAME_DEBUGGER), but I can't find where these flags are tested.  I am 
> hoping that there may be some way to defeat this and allow such code to 
> be debugged.

I've not checked in this specific case, but in a number of cases the JSD 
code will ignore calls to break into the debugger for most cases if it 
is already nested into the debugger. In other words, if you get a 
breakpoint trigger and then call some code that would ordinarily trigger 
the same/another breakpoint, it is ignored, so the debugger never nests.

If you want to try being clever, would it not be possible to - from the 
stack frame - work out the eval line number by subtracting the offset of 
the call above it? I still think SpiderMonkey needs to fix this by 
numbering the eval lines from 1 and not line-of-call. :)

-- 
James Ross <[email protected]>
ChatZilla Developer