Re: Error Stack Column number

[Art Fiedler]

I had a few thoughts on this but after evaluating it wouldn't work out...

If it were possible to modify java.lang.Throwable & StackTraceElement I had
thought to do some bit shifting to combine line & column numbers into a
negative number and place that as the line number value stored in the
LineNumberTable attribute, then converting the linenumber into line/column
in StackTraceElement. However it seems that the datatype is 2bytes only
creating a huge limitation on the size of script. Then I had thought well
maybe store the offset position as a negative number and provide a map to
get line & column... but again 2bytes isn't enough to store an offset,
less.min.js's character count is 152,193. So even if such a modification
was allowed it would not be very useful.

The other idea to push/pop on a threadlocal would I think also require a
try/finally on every method call... which I'm guessing would be a large
performance hit. In this case I would think the column number would only be
included if the error was caught in nashorn so it can populate the column
numbers on the stack... that would solve my case but it wouldn't be
consistent when caught externally.

-Arthur Fiedler

On Fri, Dec 2, 2016 at 5:25 AM, Sundararajan Athijegannathan <
sundararajan.athijegannat...@oracle.com> wrote:

> Note that nashorn always compiles to bytecode - no parallel side data
> structure for JS stacks or "interpreter stack" here.
>
> That said (if this can be done without hurting performance) we'd be
> happy to accept contributions.
>
> -Sundar
>
>
> On 12/2/2016 4:34 PM, Art Fiedler wrote:
> > Without knowing all the internals of nashorn. I don't know if an internal
> > calling tree exists or how complicated it would be to build, but it seems
> > the runtime could track function calls and maintain its own stack.
> >
> > CallNode before code is generated has the token/linenumber where it came
> > from, store a unique id of the callnode, with filename, line, column, in
> > the runtime. Then as a call node is executed push to the call stack the
> id
> > of the call node, and pop when call is complete... when the stack is
> > requested capture the current threads callnode id list (maybe use a
> thread
> > local?) match it up with the stored callnode id info map...
> merge/overwrite
> > stackelements in the stack trace gathered from Throwable.
> >
> > Well, that's what just rolled off my head of how it could possibly be
> done.
> >
> > -Arthur Fiedler
> >
> > On Fri, Dec 2, 2016 at 4:09 AM, Sundararajan Athijegannathan <
> > sundararajan.athijegannat...@oracle.com> wrote:
> >
> >> StackTraceElement being final is not the only issue here. How do to pass
> >> around & populate column numbers for the script frames?  That is the
> >> main issue here..
> >>
> >> -Sundar
> >>
> >> On 12/2/2016 3:00 PM, Art Fiedler wrote:
> >>> Yeah I almost mentioned that StackTraceElement doesn't provide a column
> >>> number to populate but removed that comment, thinking "well,
> >>> StackTraceElement could just be extended for NashornStackTraceElement",
> >> but
> >>> now looking at it I notice it's final. ugh. But it doesn't technically
> >> mean
> >>> an array of StackTraceElement's cant be converted to
> >>> NashornStackTraceElement's after getting the stack from the jvm, then
> >>> matching up script frames and populating additional information.
> >>>
> >>> -Arthur Fiedler
> >>>
> >>> On Fri, Dec 2, 2016 at 2:59 AM, Sundararajan Athijegannathan <
> >>> sundararajan.athijegannat...@oracle.com> wrote:
> >>>
>  Error has columnNumber property - but as you've noted it is not always
>  available :(  If the error is thrown from script code anywhere via
>  ECMAScript throw statement, we do populate column number - because
>  nashorn could compile the code appropriately to put column number!
> 
>  But, there are places in nashorn runtime code where ECMAScript errors
>  are thrown. For example, RangeError thrown from deep inside nashorn
>  runtime Java code! From those places, we can only recover java stack
>  trace & populate properties of ECMA error object.  As java
>  StackTraceElement objects do not have column number, we can't populate
>  column number.
> 
>  -Sundar
> 
>  On 12/2/2016 2:06 PM, Art Fiedler wrote:
> > Your right it's still not standard even in the EMCAScript 2016, it
> just
> > seems to
> > be the commonality. When thinking java yes line only makes sense as
> > typically
> > one who writes java does not minify the code. When thinking
> javascript
> > however
> > minified code is quite normal and myfile:1 might mean 5000 other
> lines
> >> as
> > well.
> >
> > I looked into the source some to see if it actually is feasible to
> >> build
>  my
> > own
> > stacktrace with file:line:column, however in the current state it
> seems
> > impossible! Nashorn actually uses java.lang.Throwable.
> getStackTrace()
> >> to
> > get 

Re: Error Stack Column number

[Sundararajan Athijegannathan]

StackTraceElement being final is not the only issue here. How do to pass
around & populate column numbers for the script frames?  That is the
main issue here..

-Sundar

On 12/2/2016 3:00 PM, Art Fiedler wrote:
> Yeah I almost mentioned that StackTraceElement doesn't provide a column
> number to populate but removed that comment, thinking "well,
> StackTraceElement could just be extended for NashornStackTraceElement", but
> now looking at it I notice it's final. ugh. But it doesn't technically mean
> an array of StackTraceElement's cant be converted to
> NashornStackTraceElement's after getting the stack from the jvm, then
> matching up script frames and populating additional information.
>
> -Arthur Fiedler
>
> On Fri, Dec 2, 2016 at 2:59 AM, Sundararajan Athijegannathan <
> sundararajan.athijegannat...@oracle.com> wrote:
>
>> Error has columnNumber property - but as you've noted it is not always
>> available :(  If the error is thrown from script code anywhere via
>> ECMAScript throw statement, we do populate column number - because
>> nashorn could compile the code appropriately to put column number!
>>
>> But, there are places in nashorn runtime code where ECMAScript errors
>> are thrown. For example, RangeError thrown from deep inside nashorn
>> runtime Java code! From those places, we can only recover java stack
>> trace & populate properties of ECMA error object.  As java
>> StackTraceElement objects do not have column number, we can't populate
>> column number.
>>
>> -Sundar
>>
>> On 12/2/2016 2:06 PM, Art Fiedler wrote:
>>> Your right it's still not standard even in the EMCAScript 2016, it just
>>> seems to
>>> be the commonality. When thinking java yes line only makes sense as
>>> typically
>>> one who writes java does not minify the code. When thinking javascript
>>> however
>>> minified code is quite normal and myfile:1 might mean 5000 other lines as
>>> well.
>>>
>>> I looked into the source some to see if it actually is feasible to build
>> my
>>> own
>>> stacktrace with file:line:column, however in the current state it seems
>>> impossible! Nashorn actually uses java.lang.Throwable.getStackTrace() to
>>> get the
>>> stack and that ends up being native. The only place you can get the
>>> columnNumber
>>> is for the specific location the error was thrown. Keyword "thrown".
>>>
>>> If you noticed my previous sample new Error().columnNumber === -1 since
>>> columnNumber is not populated... however if you throw & catch then...
>>> try { throw new Error(); }
>>> catch(e) { /* e.columnNumber === 6 */ }
>>>
>>> In my case with console.count(), the need for columnNumber is not the
>>> location
>>> of new Error() either, since the console.count() function would need the
>>> callers file:line:col as that is where console.count() is called from.
>>>
>>> In the end I still think if the stack element is from a script it should
>>> include
>>> the column number like node.js, ff, edge all seem to be doing. Since a
>> line
>>> only
>>> is useless when the script is minified. However considering that nashorn
>> is
>>> not
>>> providing the stackTrace directly, I could see why the team may not want
>> to
>>> include the columnNumber. If you do however know of another way to get
>> the
>>> callers file:line:col please let me know. My second thought was to check
>>> arguments.callee.caller for that info but no dice.
>>>
>>> -Arthur Fiedler
>>>
>>> We do not aim to provide complete compatibility with other JS
 implementations on the non-standard properties such as "stack". stack
 tries to mimic whatever is done for Java code (no column number for
 eg.). But, as you've noted there are enough information on Error objects
 via other properties like lineNumber, columnNumber, fileName. It should
 be possible to write a simple utility function to format stack string as
 desired for specific applications.

 Thanks,
 -Sundar

>>

Re: Error Stack Column number

[Art Fiedler]

Yeah I almost mentioned that StackTraceElement doesn't provide a column
number to populate but removed that comment, thinking "well,
StackTraceElement could just be extended for NashornStackTraceElement", but
now looking at it I notice it's final. ugh. But it doesn't technically mean
an array of StackTraceElement's cant be converted to
NashornStackTraceElement's after getting the stack from the jvm, then
matching up script frames and populating additional information.

-Arthur Fiedler

On Fri, Dec 2, 2016 at 2:59 AM, Sundararajan Athijegannathan <
sundararajan.athijegannat...@oracle.com> wrote:

> Error has columnNumber property - but as you've noted it is not always
> available :(  If the error is thrown from script code anywhere via
> ECMAScript throw statement, we do populate column number - because
> nashorn could compile the code appropriately to put column number!
>
> But, there are places in nashorn runtime code where ECMAScript errors
> are thrown. For example, RangeError thrown from deep inside nashorn
> runtime Java code! From those places, we can only recover java stack
> trace & populate properties of ECMA error object.  As java
> StackTraceElement objects do not have column number, we can't populate
> column number.
>
> -Sundar
>
> On 12/2/2016 2:06 PM, Art Fiedler wrote:
> > Your right it's still not standard even in the EMCAScript 2016, it just
> > seems to
> > be the commonality. When thinking java yes line only makes sense as
> > typically
> > one who writes java does not minify the code. When thinking javascript
> > however
> > minified code is quite normal and myfile:1 might mean 5000 other lines as
> > well.
> >
> > I looked into the source some to see if it actually is feasible to build
> my
> > own
> > stacktrace with file:line:column, however in the current state it seems
> > impossible! Nashorn actually uses java.lang.Throwable.getStackTrace() to
> > get the
> > stack and that ends up being native. The only place you can get the
> > columnNumber
> > is for the specific location the error was thrown. Keyword "thrown".
> >
> > If you noticed my previous sample new Error().columnNumber === -1 since
> > columnNumber is not populated... however if you throw & catch then...
> > try { throw new Error(); }
> > catch(e) { /* e.columnNumber === 6 */ }
> >
> > In my case with console.count(), the need for columnNumber is not the
> > location
> > of new Error() either, since the console.count() function would need the
> > callers file:line:col as that is where console.count() is called from.
> >
> > In the end I still think if the stack element is from a script it should
> > include
> > the column number like node.js, ff, edge all seem to be doing. Since a
> line
> > only
> > is useless when the script is minified. However considering that nashorn
> is
> > not
> > providing the stackTrace directly, I could see why the team may not want
> to
> > include the columnNumber. If you do however know of another way to get
> the
> > callers file:line:col please let me know. My second thought was to check
> > arguments.callee.caller for that info but no dice.
> >
> > -Arthur Fiedler
> >
> > We do not aim to provide complete compatibility with other JS
> >> implementations on the non-standard properties such as "stack". stack
> >> tries to mimic whatever is done for Java code (no column number for
> >> eg.). But, as you've noted there are enough information on Error objects
> >> via other properties like lineNumber, columnNumber, fileName. It should
> >> be possible to write a simple utility function to format stack string as
> >> desired for specific applications.
> >>
> >> Thanks,
> >> -Sundar
> >>
>
>

Re: Error Stack Column number

[Sundararajan Athijegannathan]

Error has columnNumber property - but as you've noted it is not always
available :(  If the error is thrown from script code anywhere via
ECMAScript throw statement, we do populate column number - because
nashorn could compile the code appropriately to put column number! 

But, there are places in nashorn runtime code where ECMAScript errors
are thrown. For example, RangeError thrown from deep inside nashorn
runtime Java code! From those places, we can only recover java stack
trace & populate properties of ECMA error object.  As java
StackTraceElement objects do not have column number, we can't populate
column number.

-Sundar

On 12/2/2016 2:06 PM, Art Fiedler wrote:
> Your right it's still not standard even in the EMCAScript 2016, it just
> seems to
> be the commonality. When thinking java yes line only makes sense as
> typically
> one who writes java does not minify the code. When thinking javascript
> however
> minified code is quite normal and myfile:1 might mean 5000 other lines as
> well.
>
> I looked into the source some to see if it actually is feasible to build my
> own
> stacktrace with file:line:column, however in the current state it seems
> impossible! Nashorn actually uses java.lang.Throwable.getStackTrace() to
> get the
> stack and that ends up being native. The only place you can get the
> columnNumber
> is for the specific location the error was thrown. Keyword "thrown".
>
> If you noticed my previous sample new Error().columnNumber === -1 since
> columnNumber is not populated... however if you throw & catch then...
> try { throw new Error(); }
> catch(e) { /* e.columnNumber === 6 */ }
>
> In my case with console.count(), the need for columnNumber is not the
> location
> of new Error() either, since the console.count() function would need the
> callers file:line:col as that is where console.count() is called from.
>
> In the end I still think if the stack element is from a script it should
> include
> the column number like node.js, ff, edge all seem to be doing. Since a line
> only
> is useless when the script is minified. However considering that nashorn is
> not
> providing the stackTrace directly, I could see why the team may not want to
> include the columnNumber. If you do however know of another way to get the
> callers file:line:col please let me know. My second thought was to check
> arguments.callee.caller for that info but no dice.
>
> -Arthur Fiedler
>
> We do not aim to provide complete compatibility with other JS
>> implementations on the non-standard properties such as "stack". stack
>> tries to mimic whatever is done for Java code (no column number for
>> eg.). But, as you've noted there are enough information on Error objects
>> via other properties like lineNumber, columnNumber, fileName. It should
>> be possible to write a simple utility function to format stack string as
>> desired for specific applications.
>>
>> Thanks,
>> -Sundar
>>

Re: Error Stack Column number

[Attila Szegedi]

Sorry, disregard the message below, it was meant for a different e-mail thread 
:-)

> On 01 Dec 2016, at 13:53, Attila Szegedi  wrote:
> 
> Okay, I tracked this down to an incorrect optimization in code generator for 
> when you use >>=0 to coerce to an uint32 :-( 
> 
> There is a special case for exactly this usage, where the right-hand-side 
> operand is a literal 0, so we avoid emitting a no-op “ICONST_0; IUSHR” 
> bytecode sequence. It unfortunately wasn’t working correctly for when the 
> left-hand-side operand of a compound-assignment-shift-right was either a 
> property or element access expression (either “obj.foo” or “obj[x]”)
> 
> Decomposing the compound assignment into an explicit shift and assignment 
> would work around the problem for now:
> 
>this.length = this.length >>> 0;  // Coerce to uint32.
> 
> I filed  > and have a fix for it.
> 
> Attila.
> 
>> On 01 Dec 2016, at 07:44, Sundararajan Athijegannathan 
>> > > wrote:
>> 
>> We do not aim to provide complete compatibility with other JS 
>> implementations on the non-standard properties such as "stack". stack tries 
>> to mimic whatever is done for Java code (no column number for eg.). But, as 
>> you've noted there are enough information on Error objects via other 
>> properties like lineNumber, columnNumber, fileName. It should be possible to 
>> write a simple utility function to format stack string as desired for 
>> specific applications.
>> 
>> Thanks,
>> -Sundar
>> 
>> On 01/12/16, 3:32 AM, Art Fiedler wrote:
>>> When making an implementation of console.count([label])  part of the
>>> Mozilla's developer docs
>>> https://developer.mozilla.org/en-US/docs/Web/API/Console/count 
>>> 
>>> mentions when label is omitted, the function will count the number of times
>>> count() was called
>>> on that line... however, if the javascript code has been minified all lines
>>> of code may be on the
>>> same line... messing up all console.count() calls...
>>> 
>>> I was providing that implementation by using new Error().stack and parsing
>>> the current file:line...
>>> however I could fix the minify issue if new Error().stack output the column
>>> also for instance...
>>> other browser seem to be doing file:line:column in the stack trace.
>>> Including nodejs see:
>>> https://nodejs.org/api/errors.html#errors_error_stack 
>>> 
>>> 
>>> Microsoft Edge's dev console outputs...
>>> new Error().stack:
>>> "Error
>>>at eval code (eval code:1:1)"
>>> Firefox since FF30:
>>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error/stack
>>>  
>>> 
>>> 
>>> Currently nashorn error stacks only include the line number...
>>> public static void main(String[] args) throws Exception {
>>> NashornScriptEngineFactory factory = new
>>> NashornScriptEngineFactory();
>>> ScriptEngine scriptEngine = factory.getScriptEngine();
>>> scriptEngine.put(ScriptEngine.FILENAME, "myfile.js");
>>> scriptEngine.eval("print('fileName: ' + new Error().fileName);");
>>> scriptEngine.eval("print('lineNumber: ' + new
>>> Error().lineNumber);");
>>> scriptEngine.eval("print('columnNumber: ' + new
>>> Error().columnNumber);");
>>> scriptEngine.eval("print('stack: ' + new Error().stack);");
>>> }
>>> /*
>>> fileName: myfile.js
>>> lineNumber: 1
>>> columnNumber: -1
>>> stack: Error
>>> at  (myfile.js:1)
>>>  */
>>> 
>>> Would be nice to add the column number to the stacks and error object in
>>> nashorn.
>>> 
>>> Thanks,
>>> Arthur Fiedler
> 

Re: Error Stack Column number

[Attila Szegedi]

Okay, I tracked this down to an incorrect optimization in code generator for 
when you use >>=0 to coerce to an uint32 :-( 

There is a special case for exactly this usage, where the right-hand-side 
operand is a literal 0, so we avoid emitting a no-op “ICONST_0; IUSHR” bytecode 
sequence. It unfortunately wasn’t working correctly for when the left-hand-side 
operand of a compound-assignment-shift-right was either a property or element 
access expression (either “obj.foo” or “obj[x]”)

Decomposing the compound assignment into an explicit shift and assignment would 
work around the problem for now:

   this.length = this.length >>> 0;  // Coerce to uint32.

I filed > and have a fix for it.

Attila.

> On 01 Dec 2016, at 07:44, Sundararajan Athijegannathan 
>  wrote:
> 
> We do not aim to provide complete compatibility with other JS implementations 
> on the non-standard properties such as "stack". stack tries to mimic whatever 
> is done for Java code (no column number for eg.). But, as you've noted there 
> are enough information on Error objects via other properties like lineNumber, 
> columnNumber, fileName. It should be possible to write a simple utility 
> function to format stack string as desired for specific applications.
> 
> Thanks,
> -Sundar
> 
> On 01/12/16, 3:32 AM, Art Fiedler wrote:
>> When making an implementation of console.count([label])  part of the
>> Mozilla's developer docs
>> https://developer.mozilla.org/en-US/docs/Web/API/Console/count
>> mentions when label is omitted, the function will count the number of times
>> count() was called
>> on that line... however, if the javascript code has been minified all lines
>> of code may be on the
>> same line... messing up all console.count() calls...
>> 
>> I was providing that implementation by using new Error().stack and parsing
>> the current file:line...
>> however I could fix the minify issue if new Error().stack output the column
>> also for instance...
>> other browser seem to be doing file:line:column in the stack trace.
>> Including nodejs see:
>> https://nodejs.org/api/errors.html#errors_error_stack
>> 
>> Microsoft Edge's dev console outputs...
>> new Error().stack:
>> "Error
>>at eval code (eval code:1:1)"
>> Firefox since FF30:
>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error/stack
>> 
>> Currently nashorn error stacks only include the line number...
>> public static void main(String[] args) throws Exception {
>> NashornScriptEngineFactory factory = new
>> NashornScriptEngineFactory();
>> ScriptEngine scriptEngine = factory.getScriptEngine();
>> scriptEngine.put(ScriptEngine.FILENAME, "myfile.js");
>> scriptEngine.eval("print('fileName: ' + new Error().fileName);");
>> scriptEngine.eval("print('lineNumber: ' + new
>> Error().lineNumber);");
>> scriptEngine.eval("print('columnNumber: ' + new
>> Error().columnNumber);");
>> scriptEngine.eval("print('stack: ' + new Error().stack);");
>> }
>> /*
>> fileName: myfile.js
>> lineNumber: 1
>> columnNumber: -1
>> stack: Error
>> at  (myfile.js:1)
>>  */
>> 
>> Would be nice to add the column number to the stacks and error object in
>> nashorn.
>> 
>> Thanks,
>> Arthur Fiedler

Re: Error Stack Column number

[Sundararajan Athijegannathan]

We do not aim to provide complete compatibility with other JS 
implementations on the non-standard properties such as "stack". stack 
tries to mimic whatever is done for Java code (no column number for 
eg.). But, as you've noted there are enough information on Error objects 
via other properties like lineNumber, columnNumber, fileName. It should 
be possible to write a simple utility function to format stack string as 
desired for specific applications.


Thanks,
-Sundar

On 01/12/16, 3:32 AM, Art Fiedler wrote:

When making an implementation of console.count([label])  part of the
Mozilla's developer docs
 https://developer.mozilla.org/en-US/docs/Web/API/Console/count
mentions when label is omitted, the function will count the number of times
count() was called
on that line... however, if the javascript code has been minified all lines
of code may be on the
same line... messing up all console.count() calls...

I was providing that implementation by using new Error().stack and parsing
the current file:line...
however I could fix the minify issue if new Error().stack output the column
also for instance...
other browser seem to be doing file:line:column in the stack trace.
Including nodejs see:
 https://nodejs.org/api/errors.html#errors_error_stack

Microsoft Edge's dev console outputs...
 new Error().stack:
 "Error
at eval code (eval code:1:1)"
Firefox since FF30:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error/stack

Currently nashorn error stacks only include the line number...
 public static void main(String[] args) throws Exception {
 NashornScriptEngineFactory factory = new
NashornScriptEngineFactory();
 ScriptEngine scriptEngine = factory.getScriptEngine();
 scriptEngine.put(ScriptEngine.FILENAME, "myfile.js");
 scriptEngine.eval("print('fileName: ' + new Error().fileName);");
 scriptEngine.eval("print('lineNumber: ' + new
Error().lineNumber);");
 scriptEngine.eval("print('columnNumber: ' + new
Error().columnNumber);");
 scriptEngine.eval("print('stack: ' + new Error().stack);");
 }
 /*
 fileName: myfile.js
 lineNumber: 1
 columnNumber: -1
 stack: Error
 at  (myfile.js:1)
  */

Would be nice to add the column number to the stacks and error object in
nashorn.

Thanks,
Arthur Fiedler