Stacktraces from dynamically-constructed functions not as expected

[Hannes Wallnoefer]

Am 2016-05-12 um 23:42 schrieb Vivin Suresh Paliath:
> Thanks for the explanation Hannes! The issue with $ makes sense; I ran 
> into that some time ago - I can't remember the exact situation, but it 
> was exactly as you described: the $ introduces ambiguity because it is 
> a valid character and so could be part of the name of the original 
> function, and not a separator. Would you be able to point me to the 
> location in the nashorn source where this mapping/translation is done? 
> It would help me learn more about the internals of nashorn.

The method name is created in Parser#createParserContextFunctionNode:
http://hg.openjdk.java.net/jdk9/dev/nashorn/file/4b118e012ac4/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java#l532

The method name for the stack trace is computed in 
NashornException#getScriptFrames:
http://hg.openjdk.java.net/jdk9/dev/nashorn/file/4b118e012ac4/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/scripting/NashornException.java#l174

I've filed a bug for this: https://bugs.openjdk.java.net/browse/JDK-8156896

Hannes

>
> On Thu, May 12, 2016 at 2:12 PM, Hannes Wallnoefer 
> <hannes.wallnoefer at oracle.com <mailto:hannes.wallnoefer at oracle.com>> 
> wrote:
>
>     Hi Vivin,
>
>     What you see is some fuzziness in the translation from JS
>     functions to Java methods and from there to the stack traces you see.
>
>     When we compile a JS function, we create a Java method with the
>     name of the function concatenated to the names of its parent
>     functions, using '$' as separator. For anonymous functions we use
>     something like L:123 as name where 123 is the line of code where
>     the function begins.
>
>     This method naming scheme helps a lot in making bytecode easier to
>     debug, and to create unique method names within a compilation
>     unit. However, it also leads to the stack traces you see, getting
>     f$foo in the first case and something like L1:foo in the second
>     case, which is rendered as <anonymous> in the stack trace.
>
>     Ideally we should reverse this when printing stack traces,
>     displaying only the name of the function itself, e.g. "bar" for
>     "foo$bar" and "<anonymous>" for "foo$L:3". Unfortunately, "$" is a
>     valid character in a JS identifier, so it's not that easy,
>     "foo$bar" may also be the name of the original function.
>
>     I'm thinking about how to solve this and will probably file an
>     issue for it.
>
>     Hannes
>
>     Am 2016-05-12 um 15:59 schrieb Vivin Suresh Paliath:
>
>         I tried this out on in chrome and I get the expected stack
>         trace there. Is
>         this a bug?
>         On May 6, 2016 3:39 PM, "Vivin Suresh Paliath"
>         <vivin.paliath at gmail.com <mailto:vivin.paliath at gmail.com>>
>         wrote:
>
>             I have the following code:
>
>             *var f = (function() {*
>             *    return function foo() {*
>             *        try {*
>             *            throw new Error();*
>             *        } catch(e) {*
>             *            print(e.stack);*
>             *        }*
>             *    }*
>             *})();*
>
>
>             When I call the function, I get the following stacktrace
>             as expected
>             (mostly; I was expecting *foo* instead of *f$foo*).
>
>             *Error*
>             *        at f$foo (<shell>:1)*
>             *        at <program> (<shell>:1)*
>
>
>             However, if I dynamically construct the function as follows:
>
>             *var f = new Function([], "return function foo() { try {
>             throw new
>             Error(); } catch(e) { print(e.stack); } }")()*
>
>
>             I get:
>
>
>             *Error*
>             *        at <anonymous> (<function>:2)*
>             *        at <program> (<shell>:1)*
>
>
>             Is there a reason for this discrepancy? Isn't the second
>             version
>             effectively the same as the first? Also, why is it *f$foo*
>             instead of
>             *foo* in the first case?
>
>             I am running jdk8u92.
>
>             Thanks!
>
>             --
>             Ruin untold;
>             And thine own sadness,
>             Sing in the grass,
>             When eve has forgot, that no more hear common things that
>             gleam and pass;
>             But seek alone to lip, sad Rose of love and ruin untold;
>             And thine own mother
>             Can know it as I know
>             More than another
>             What makes your own sadness,
>             Set in her eyes.
>
>             map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02".
>             ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01".
>             ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01".
>             ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02".
>             ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02".
>             ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01".
>             ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01".
>             ":13:02:11:01:02:11:01:12:02";map{print chr unpack"
>             i",pack"B32",$_}$j=~m/.{8}/g
>
>
>
>
>
> -- 
> *[vivin.net <http://vivin.net>:: github <http://github.com/vivin>:: 
> linkedin <https://www.linkedin.com/in/vivin>]*