Maximally minimal stack trace standardization

John Lenz concavelenz at gmail.com
Tue Mar 10 00:02:25 UTC 2015


On Mon, Mar 9, 2015 at 12:15 PM, Mark S. Miller <erights at google.com> wrote:

> On Sat, Mar 7, 2015 at 2:55 PM, John Lenz <concavelenz at gmail.com> wrote:
>
>> I wanted to ping this thread and see how we could get "max-min stack
>> traces" to the next step?
>>
>
> Hi John, the best way to take this to the next step is to read <
> https://docs.google.com/document/d/1QbEE0BsO4lvl7NFTn5WXWeiEIBfaVUF7Dk0hpPpPDzU/edit>
> and submit a proposal to <https://github.com/tc39/ecma262>.
>
> "If you are a TC39 member representative, just submit a pull request for
> your proposal."
>
> Since you are at a member organization, attend and participate actively at
> TC39 meetings to advance your proposal through the process.
>
> Please keep in mind that the stack trace information should not be
> available simply from the error object by itself, as that is a bad
> information leak.
>

The threads I dug up, simply state what you state here.  That there is an
"information leak".  Are filename and function names considered sensitive?
In what way?   I did not intend to promote a "rich stack inspection API"
such as V8 has.


> See the previous es-discuss discussions of the need for something like the
> getStack function of <
> https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js#300>
> for rights amplification.
>
> Other proposals-to-be that need to traffic in source positions are
> * source maps
> * passing source position through an eval
> * causality tracking for multi-turn computation; at least deep stacks
> * adding source positions/maps to the template objects of template strings.
>
> Of course, these should be as decoupled as possible. But it's good to keep
> your eye on the whole picture when you start standards work that depend on
> source positions.
>

>
>
>> On Fri, Oct 10, 2014 at 11:47 AM, Frankie Bagnardi <f.bagnardi at gmail.com>
>> wrote:
>>
>>> I think this is a great idea.  I often use stack traces, especially in
>>> node.js, for debug error messages and logging.  This would make it much
>>> simpler to work with them.
>>>
>>> Also there are some libraries which end up with a lot of wrapped
>>> functions, which could be omitted using an error cleaner function.
>>>
>>> I suggest a stackTrace property (getter, no write) of Error objects:
>>>
>>>  - .frames is an array of stack frame metadata objects
>>>  - no concept of sourcemaps
>>>  - [[ToString]] is left implementation dependant, allowing them to add
>>> information from sourcemaps, or otherwise customize it
>>>
>>> This allows for a programmable api, and a human readable version.  Also
>>> devtools and other code applications (like Carl Smith's) can create rich
>>> UIs for this data.
>>>
>>> I'm sure the smart people at TC39 can come up with a good (or good
>>> enough) way to represent PTCs.
>>>
>>>
>>>
>>> On Sat, Oct 4, 2014 at 9:31 AM, John Lenz <concavelenz at gmail.com> wrote:
>>>
>>>> Is ES6 "shipping" PTCs without implementer feedback? Or how have those
>>>> that tried dealt with stack traces?
>>>> On Sep 29, 2014 3:20 PM, "John Lenz" <concavelenz at gmail.com> wrote:
>>>>
>>>>> What does TC39 expect with regard to PTC and the
>>>>> standard-because-everyone-has-one "stack" property?   Has any of the VMs
>>>>> actually tried to implement PTC for JS?
>>>>>
>>>>> On Mon, Sep 29, 2014 at 12:02 PM, Brendan Eich <brendan at mozilla.org>
>>>>> wrote:
>>>>>
>>>>>> Allen Wirfs-Brock wrote:
>>>>>>
>>>>>>> No particular reason an implementation can't optimize through that
>>>>>>> if they want to.
>>>>>>>
>>>>>>
>>>>>> The question is whether it should be normative. PTC is about
>>>>>> observable asymptotic space performance (I keep saying :-P).
>>>>>
>>>>>
>
>
>
> --
>     Cheers,
>     --MarkM
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150309/a4944c3e/attachment.html>


More information about the es-discuss mailing list