This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 247441 - IllegalStateException: Can not create file '6911ca99//Users/dcaldwell/tools/sdk/jsh/script/jsh/nashorn.js#15:15<eval>@1.js' parent = null
Summary: IllegalStateException: Can not create file '6911ca99//Users/dcaldwell/tools/s...
Status: REOPENED
Alias: None
Product: javascript
Classification: Unclassified
Component: Debugger (show other bugs)
Version: 8.0
Hardware: All All
: P3 normal with 1 vote (vote)
Assignee: Martin Entlicher
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-24 12:26 UTC by inonit
Modified: 2014-09-29 20:33 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 212176


Attachments
stacktrace (1.44 KB, text/plain)
2014-09-24 12:26 UTC, inonit
Details
A patch which fixes issue for my first test case (920 bytes, patch)
2014-09-25 20:36 UTC, inonit
Details | Diff
Fixes issue in stepping into eval code in Nashorn (862 bytes, patch)
2014-09-28 18:53 UTC, inonit
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description inonit 2014-09-24 12:26:09 UTC
This bug was originally marked as duplicate of bug 245245, that is already resolved. This bug is still valid, so this seems to be another bug, but it might be related.

Build: NetBeans IDE 8.0.1 (Build 201408251540)
VM: Java HotSpot(TM) 64-Bit Server VM, 25.20-b23, Java(TM) SE Runtime Environment, 1.8.0_20-b26
OS: Mac OS X

User Comments:
inonit: trying to enter Nashorn script via attaching debugger

mentlicher: Debugging a trivial avatar.js application.

inonit: Slightly different version of previous report. Seems to happen when Nashorn source file is not available in IDE.

inonit: Problem happens even if source file is in open project in IDE




Stacktrace: 
java.lang.IllegalStateException: Can not create file '6911ca99//Users/dcaldwell/tools/sdk/jsh/script/jsh/nashorn.js#15:15<eval>@1.js' parent = null
   at org.netbeans.modules.debugger.jpda.js.source.SourceFS.createFile(SourceFS.java:143)
   at org.netbeans.modules.debugger.jpda.js.source.SourceFilesCache.getSourceFile(SourceFilesCache.java:77)
   at org.netbeans.modules.debugger.jpda.js.source.Source.<init>(Source.java:106)
   at org.netbeans.modules.debugger.jpda.js.source.Source.getSource(Source.java:225)
   at org.netbeans.modules.debugger.jpda.js.breakpoints.JSJavaBreakpointsManager$ScriptsHandler.breakpointReached(JSJavaBreakpointsManager.java:303)
   at org.netbeans.api.debugger.jpda.JPDABreakpoint.fireJPDABreakpointChange(JPDABreakpoint.java:300)
Comment 1 inonit 2014-09-24 12:26:12 UTC
Created attachment 149494 [details]
stacktrace
Comment 2 inonit 2014-09-25 11:39:15 UTC
I have a fix that works for my use case. However, I know a lot more about Nashorn than NetBeans and I know a lot more about my embedding of Nashorn than I do about either. So I wouldn't consider it a quality contribution; more like a cobbled-together patch based on very little understanding of the surrounding code. But it works!

I am going to examine the guidelines for contributions and try to figure out what I am supposed to do next.
Comment 3 inonit 2014-09-25 20:36:17 UTC
Created attachment 149526 [details]
A patch which fixes issue for my first test case

I am still learning the design of the module but here's a first cut that allows my test case to pass.

I am running a Hello, World script using a custom Nashorn embedding that loads lots of files. This fixes two issues: it allows the debugger to find files using absolute paths if their absolute paths are provided via ScriptEngine.FILENAME, and it essentially causes the debugger to ignore files loaded via script-side eval(), although in principle it should be possible to debug those, too, given that their source is available at runtime.

Anyway, first attempt.
Comment 4 Martin Entlicher 2014-09-26 17:01:04 UTC
I'll add the check for the existence of absolute paths, thanks for that.
But I want to retain the availability of sources created during eval. It looks like we need to fix something in SourceFS class. Steps to reproduce are welcomed.
Comment 5 Martin Entlicher 2014-09-26 18:48:36 UTC
Should be fixed by http://hg.netbeans.org/core-main/rev/a3c61574bf42
A test for handling of various names added.
Comment 6 Quality Engineering 2014-09-28 01:57:36 UTC
Integrated into 'main-silver', will be available in build *201409280001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/a3c61574bf42
User: mentlicher@netbeans.org
Log: #247441: Correct the handling of sources, test included.
Comment 7 inonit 2014-09-28 18:53:35 UTC
Created attachment 149568 [details]
Fixes issue in stepping into eval code in Nashorn
Comment 8 inonit 2014-09-28 18:58:29 UTC
Reopening because JavaScript code executed by JavaScript eval() does not show up correctly in debugger. An attempt to step into it succeeds but the code does not display and the IDE displays the No_URL_Warning message because it cannot connect the source code properly.

The problem is that the default "stratum" is computed incorrectly. CallStackFrameImpl tries to parse a string like:

/Users/dcaldwell/tools/jsh/0.0.4.9/script/jsh/nashorn.js#14:15<eval>@0

by looking after the last period and uppercasing the string. So it thinks the "stratum" is:

JS#14:15<EVAL>@0

... which is not "JS" or "Java," so the IDE is not able to resolve the source code properly.

The attached patch augments the '.' heuristic to strip everything after a '#' in order to fix this issue.
Comment 9 Martin Entlicher 2014-09-29 16:22:12 UTC
Well, I wonder why one more ".js" is not appended to the whole path.
CallStackFrameImpl is too generic for such patch IMHO and it does not look nice to me to adjust some specific extensions.

There is a test for ".js" extension in org.netbeans.modules.debugger.jpda.js.source.Source class on line 224. The ".js" extension is added if there is not one, which is this case. Can you please check that the name passed to new Source(...) has the .js extension? It does work for me.
Comment 10 inonit 2014-09-29 16:43:05 UTC
I don't know why, but I can say this:

In line 293 of CallStackFrameImpl, the getSourceName(null) call returns:

"/Users/dcaldwell/tools/jsh/0.0.4.9/script/jsh/nashorn.js#14:15<eval>@0"

I have not yet figured out how the Location and LocationWrapper stuff works, so I can go there next.

As for whether CallStackFrameImpl is too generic for this patch, I can't see why. Just a few lines down is this code:

// Check Nashorn:
String sourcePath = getSourcePath(null);
if (sourcePath.startsWith("jdk/nashorn/internal/scripts/") ||       // NOI18N
    sourcePath.startsWith("jdk\\nashorn\\internal\\scripts\\")) {   // NOI18N
    s = "JS";                                                   // NOI18N
    as = Collections.singletonList(s);
}

... so it seems to me like we're already very Nashorn-aware in this code.

I'll keep digging and see if I can figure out Location and LocationWrapper.
Comment 11 inonit 2014-09-29 20:23:21 UTC
So here's what I think. Everything is predicated on the assumption that com.sun.jdi.Location and com.sun.jdi.ReferenceType are things provided by the JVM (and thus, indirectly, Nashorn), and not produced by NetBeans itself. I think that's true (see documentation below), but if I'm wrong, we'll need to re-analyze.

If it *is* true, then:

1. Tools like Nashorn and preprocessors (JSP, for example) can provide something called  a "stratum" to allow tools to map VM information back to source information. See http://docs.oracle.com/javase/7/docs/jdk/api/jpda/jdi/com/sun/jdi/Location.html.

2. When the tools do not provide it, NetBeans attempts to infer it. See CallStackFrameImpl, starting at line 290, where the implementation attempts to infer the stratum and stuff it into the stratum variable 's'.

3. For other languages, NetBeans uses two heuristics: one based on the file extension (uppercase the file extension and that's the stratum) and another, based on whether the path contains jdk/nashorn/internal/scripts/ or the Windows equivalent; in that case, it uses "JS".

4. However, when Nashorn executes an internal eval (i.e., the JavaScript eval, from within a script), it generates a filename like blah/blah/blah.js#eval(line:column)@n. The NetBeans heuristics do not contemplate this sort of filename, and thus incorrectly applies the first rule above and ends up with JS#EVAL(line:column)@n

5. Therefore, CallStackFraceImpl *is* the correct place to "fix" this. We are attempting to infer the stratum and should use the best information available to do so. In this case, my patch correctly recognizes the Nashorn eval format and parses it. It is possible there is a more general approach.

But basically, I don't think this has anything to do with JavaScript specifically or with the JavaScript debugger specifically. The debugger can tack all the ".js" extensions on it wants -- but *Nashorn* is providing the file in a way our code can't affect it here (from an internal eval(), which never reaches us, and generates Location and ReferenceType objects without our intervention). As such, we should fix the stratum here, rather than put a workaround in the JavaScript debugger.

Unless I'm wrong about where Location and ReferenceType originate, of course.
Comment 12 inonit 2014-09-29 20:33:03 UTC
Just to close the loop, I think the right place to fix the stratum is in CallStackFrameImpl, but the way the symptom eventually manifests is that the incorrect stratum value is passed back into the JavaScript debugger, to the FirstSourceURLProvider class getURL() method. That method checks to see whether the stratum is "JS". Since it is not (it is "JS#EVAL..."), it returns null, which the debugger interprets as "can't locate the source." If the stratum is fixed (for example, via the provided patch), things work as intended.