debugging interfaces

Mark S. Miller erights at google.com
Mon Jun 15 19:31:17 PDT 2009


On Mon, Jun 15, 2009 at 5:06 AM, Jordan Osete <jor at joozt.net> wrote:

> Hi everybody.
>
> I've wondered for some time if it weren't possible to harmonize stack
> traces across browsers.
> I have submitted a (simple) proposal on the WHATWG mailing list (
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020359.html),
> and got somehow "redirected" here ;-)
>
> So here is the proposal, as I first submitted it. Please tell me if it is
> not exactly the best place for this.


This is the best place. Thanks for posting.



> Part of the functionality proposed here also assumes a browser environment
> (html / js files) which probably cannot be implemented in some other
> environments (like JS interpreters).
> Also I do not care that much about the proposed property names. They are
> just here as examples.
>
> Note: unfortunately, I do not "speak" Java at all, and thus I don't know
> JVM TI. I only skimmed through "JavaTM Virtual Machine Tool Interface (JVM
> TI)" (http://java.sun.com/javase/6/docs/technotes/guides/jvmti/), but it
> seems it goes far beyond what I describe here.
>

It does indeed. I do not suggest that a debugging API be modeled on it in
any detail. However, it does have one great virtue: it is stratified in the
sense explained by <http://bracha.org/mirrors.pdf> and not generally
accessible from within the computation being reflected upon. This is
essential to reconcile debuggability with strong encapsulation.

In particular, one of the motivations for introducing strict mode into es5
is so that the encapsulation of strict functions can be safe even from
non-strict functions. This is explained starting at slide <
http://google-caja.googlecode.com/svn/trunk/doc/html/es5-talk/img39.html>
which corresponds to minute 41 of <
http://www.youtube.com/watch?v=Kq4FpMe6cRs>. However, the mechanisms
explained there were insufficient, resulting in the following agreement at
the last EcmaScript meeting:

On Mon, Jun 1, 2009 at 5:11 PM, Waldemar Horwat <waldemar at google.com> wrote:

> Rather than describing the evil things that implementations do with
> F.caller, we agreed to just impose a blanket prohibition of code peeking
> into the environment records or identity of strict functions on the stack.
>  This way a test suite can ensure that F.caller does nnot reveal strict
> functions without us having to introduce the evil things into the standard.
>  I'll write up proposed wording.
>





>
> -----------------------------------------------
>
> * What is the problem you are trying to solve? *
> If you want a traceback, you need to cater for multiple browsers
> behaviours, and different and incomplete information.
>
> * What is the feature you are suggesting to help solve it? *
> Harmonize JavaScript stack traces across browsers. There could be a global
> getStackTrace() method, wich would return an array of stack frames, closest
> one first (or last, I don't care). Every stack frame object could have the
> following properties:
>
> To identify what script we are in:
> - the script filename, if external script (JSFileName)
> - or HTML filename, in case of an inline script (HTMLFileName)
> - or, in case of an "eval()" call, a special evalScope property must be
> set to true
> - a reference to the script tag DOM object, if the script was not eval'd
> (scriptTag)
>
> To identify where in the script we are:
> - a simple way to get the script's full source code, whatever way it is
> eval'd or included. For example, a fullJSSourceCode property
> - the line number, relative to the start of the script (sourceLine)
> - the line number, relative to the start of the file containing the
> script. It is equal to sourceLine, except if it is an inline script in
> an HTML file (fileLine)
> - the position of the substring delimiting the instruction in the source
> code, relative to the start of the line. This is especially useful if
> the JS source is "packed" or minifed, and thus newlines have been
> suppressed (instructionOffsetStart and instructionOffsetEnd)
>
> And about the environment:
> - a reference to the "this" object in the given stack frame (thisObj)


If the debugging API is unstratified or generally accessible, this violates
encapsulation.


>
> - a reference to the function called (func). This is a function object.


If the debugging API is unstratified or generally accessible, this violates
encapsulation.

- the arguments the function was called with, just like the arguments
> pseudo-array in a function (arguments)


If the debugging API is unstratified or generally accessible, this violates
encapsulation.

>
> - a reference to the variable object, that carries all of the variables
> that have been defined with the "var" statement, and that can be
> accessed in this stack frame ? (variables)
>

If the debugging API is unstratified or generally accessible, this violates
encapsulation.


However, if the debugging API is constructed and made available in a way
that doesn't violate security, your list above may be a good start. Thanks.

-- 
   Cheers,
   --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20090615/24e46862/attachment.html>


More information about the es-discuss mailing list