debugging interfaces

Christian Plesner Hansen christian.plesner.hansen at gmail.com
Thu Aug 13 00:38:38 PDT 2009


Having recently implemented stack traces in v8 I can provide some
input on this from an implementation perspective.

We have pretty strict performance requirements so I did a lot of
experimentation to see how much information could be collected without
affecting performance noticeably.  The result was that it was feasible
to collect the value of this, the function being called, and the
current position within the function.  Collecting arguments would have
been too expensive.  Collecting variables would have been much too
expensive.

Processing the stack trace, say converting objects to JSON, isn't a
big problem from a performance perspective as long as the processing
doesn't have to happen when the stack trace is captured.  In v8 we
capture a "bare metal" trace when an error is created and use an
accessor to get the .stack property which formats the stack trace the
first time it is read.

Stack traces should not be limited to built-in errors, they should be
available and efficient for user-defined errors as well.  In v8 we
have an Error.captureStackTrace(error, cutoff_opt) function that
allows you to attach a stack trace to any object, say:

function MyError(message) {
  this.message = message;
  Error.captureStackTrace(this, MyError);
}

If you pass a function as the cutoff argument all stack frames above
and include the topmost call to that function will not be included in
the stack frame.  This was intended to solve the getStackTrace problem
you describe in the proposal but it turns out that it can also be
useful to hide more of the stack trace, to avoid cluttering it with
the internal mechanics of library code.

Having a getStackTrace function might be useful but is problematic
because, as I read it, it both collects and formats the stack trace,
which is expensive.  For performance reasons we want to postpone
formatting using an accessor.  That's the reason for the otherwise odd
api of passing the error object into captureStackTrace and having it
set up the appropriate accessor.


-- Christian

On Thu, Aug 13, 2009 at 12:33 AM, Jordan Osete<jor at joozt.net> wrote:
> (Sorry for the late answer. Other stuff got this thread out of my mind.)
>
> I understand that specifying a complete stratified API is necessary, however
> as it is still far from being ready yet, would it still be possible to
> implement something close to my first proposal (minus the offending parts) ?
> As it stays quite simplistic (and only requires defining a single function),
> it could be ready much earlier, and would be a convenient replacement for
> the time being, until a complete stratified API is ready.
>
> Well, just in case, here is what I would change about it today:
>
> ----------------------------
>
> Keep some kind of global getStackTrace() function to get an array of stack
> frames. Each stack frame object has a number of properties to provide
> information about the given stack frame. I had divided this proposal in
> sections:
>
> To identify what script we are in ("Script identification" section):
> - I would not remove anything from this section.
> - Maybe add an evalSourceURL property to identify the source file name for
> "named evals" (with "hacks" like this one, if something like that is ever
> standardized:
> http://blog.getfirebug.com/2009/08/11/give-your-eval-a-name-with-sourceurl/).
>
> To identify where in the script we are ("In-script localization"):
> - I would keep this section as it is.
>
> And about the environment:
> - This is the offending part that needs rewriting, as it is the one to
> propose providing direct references to objects and functions in the running
> environment (thus violating the JS-closures encapsuiation mechanism).
> - To avoid the direct references, while still providing most of the
> available information, those objects could be converted to a different
> representation of them, a representation which would not expose everything
> we want to keep safe.
> For example, the implementation could transform the object to JSON and
> provide the JSON'ed representation (it would have to watch for circular
> references though). Or create something like a "structured clone"
> (http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#structured-clone),
> or anything of the sort.
> - It would still not be perfect, as it would provide no information for
> things like circular references, nor functions, or native objects (both JSON
> and structured-cloning algorythms would have to ignore any of these). It
> would also not allow testing for strict equality between objects, etc.
> However, it would still provide a bunch of useful information, hopefully
> enough for most use cases, while still keeping it simple.
> Actually, I really like the idea of using JSON. It is something that already
> exists, is well known, well understood, human readable, and widely
> supported. As it is a string, it can also easily be sent to a server or
> stored somewhere for later inspection.
> - So for example, if we use JSON representation, 3 properties would remain
> for this section: thisObj (the JSON-Representation of the this object in the
> given stack frame), arguments (JSON-R of the arguments object), and
> variables (key-value  pairs containing information about every variable
> accessible in the stack frame). The function object currently executed can
> not be represented.
>
> I hope this makes the proposal more acceptable. It can of course still be
> improved or extended.
>
> Regards,
>
> Jordan OSETE
>
>
> Mark S. Miller a écrit :
>
> On Tue, Jun 16, 2009 at 7:18 AM, Jordan Osete <jor at joozt.net> wrote:
>>
>> After a quick look into this PDF (very instructive, thanks), I think I
>> understand the advantages of having a mirror API that is clearly distinct
>> from the rest of the ES API.
>> However, ES already has a number of reflection features built in, that are
>> clearly not stratified. From the prototype and constructor property,
>> for...in statements that allow to list properties, typeof, instanceof,
>> including new ones like the functions to __define / __lookup a Getter__ /
>> Setter__,
>
> Yes, JavaScript is already pervasively reflective in a non-stratified way.
> However, none of these violate the encapsulation of the one and only
> encapsulation mechanism present in EcmaScript -- functions evaluating to
> lexical closure that capture the variables in their scope. All the new
> reflective operators introduced by ES5 were careful to respect this boundary
> as well. De-facto JavaScript does have further reflective operators that do
> violate encapsulation -- <function-instance>.caller,
> <function-instance>.arguments, arguments.caller, and arguments.callee. ES5
> specifies that these be disabled for strict functions so that the
> encapsulation of strict functions remains defensible.
>
>>
>> including the actual stack traces API (like the Mozilla Stack object
>> https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Objects/Error/stack).
>
> This does violate information encapsulation and so does threaten
> confidentiality. However, it provides no access and so does not threaten
> integrity.
>
>>
>> Also, there are a variety of environments a JS "thread" can run in today.
>> For browsers, it may run in an HTML page, or in a Web worker, but it may
>> also run in a command-line interpreter, and even as a server-side language.
>> Will all those need different ways to get JS threads for examination ?
>>
>> As for the browser, for example (sorry, it is by far the environment I am
>> most familiar with), I think it would be nice to still allow a page to
>> access this mirror API to "explore" another page, without needing explicit
>> user consent under certain conditions (like a same-origin policy for the
>> inspector / inspected page, for example). Test suites come to mind.
>> Would this kind of things be acceptable, from a security point of view ?
>
> Not by itself, no.
>
>>
>> It *seems* Opera Dragonfly is using some kind of "Scope" thing as its
>> mirror / proxy API
>> (http://dev.opera.com/articles/view/opera-dragonfly-architecture/), and then
>> the rest is pure web (Opera developers' insight would be welcome on that
>> matter).
>> However (still about the browser), even the proxy part can be moved to
>> pure web technologies (like XHR, through some server), in a debugging lib.
>> That would leave only the mirror API to define in the standard.
>
>
> Will take a look. Thanks for the pointer.
>
> --
>    Cheers,
>    --MarkM
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


More information about the es-discuss mailing list