Could not load source '': SourceRequest: property 'sourceReference' is missing, null, or empty.

[cshung]

Cannot load source code during Java debugging in a certain scenario.

Environment

• Operating System: OSX
• JDK version: 1.8.0_201
• Visual Studio Code version: 1.30.2
• Java extension version:0.6.0
• Java Debugger extension version:0.17.0

Steps To Reproduce

1. Clone and build the google closure compiler at https://github.com/google/closure-compiler
2. Set a breakpoint at src/com/google/javascript/jscomp/PeepholeCollectPropertyAssignments.java
3. Build the project using maven (instruction included at the front page of the repo)
4. Debug

Current Result

The breakpoint hits, but then loading sour code fails with this error.
Could not load source '': SourceRequest: property 'sourceReference' is missing, null, or empty.

Expected Result

Loading source code should work.

Additional Information

This is a clone of issue 550 in the vscode-java-debug repo. I believe the root cause of the bug is in this repo, so I cloned the issue over.

I believe I have some idea why the scenario is failing:

1. When the debuggee stops - VSCode calls getCallStackImpl(), when it is done, the sources are retrieved and stored in a cache. The source reference of the source object retrieved by the getCallStackImpl() is probably produced by convertDebuggerSourceToClient which hardcoded 0 (three times in different cases) for the sourceReference parameter.
2. Then VSCode is trying to load the source, it invokes the createOrUpdateContentModel function to do so. It made some attempt to consult the modelService. In my scenario, it fails, and it use the debug session to load sources using the previously generated Uri and source reference. I believe it will eventually end up at here, obviously it will fail because source reference is 0.
3. I think there might be an easy fix. We can create a source reference when we produce a stack trace, and then we should be able to resolve by the time we are done.

I submitted a pull request for my idea in 3, I haven't been able to test this yet.

[testforstephen]

@cshung Reference Debug Adapter Protocol, we set sourceReference to 0 by design. Because if the debugger is able to find the right source mapping, it will set the uri to the path field of Source object directly, then VS Code will find the appropriate editor to open the uri. (Use text editor to open file://xyz uri, and jdt content provider to open jdt://xyz uri.)

SourceRequestHandler.java is deprecated, will not be invoked by Java Debugger.

[testforstephen]

To help us investigate your issue, could you change vscode user settings "java.debug.logLevel": "verbose"?

After that, start debugging and debug protocol data will be logged. The log can be viewed by the vscode command Java: Open Java Language Server log file. And share us the log file.

[cshung]

log.txt

[testforstephen]

"source":{"name":"PeepholeCollectPropertyAssignments.java","path":"./src/com/google/javascript/jscomp/PeepholeCollectPropertyAssignments.java","sourceReference":0}

it looks like vscode doesn't support relative path in the source.path field. Did you manually configure sourcePaths to a relative path ./src in launch.json?

[cshung]

Yes, I did set a relative path in my launch.json.
Once I change it into an absolute path it works, although I think we should handle relative path though.

[testforstephen]

Yeah, we can improve it by appending workspaceFolder as the prefix if a relative path is found.

Currently, you can specify "sourcePaths": ["${workspaceFolder}/src"] as a workaround.

[dassio]

@cshung Reference Debug Adapter Protocol, we set sourceReference to 0 by design. Because if the debugger is able to find the right source mapping, it will set the uri to the path field of Source object directly, then VS Code will find the appropriate editor to open the uri. (Use text editor to open file://xyz uri, and jdt content provider to open jdt://xyz uri.)

SourceRequestHandler.java is deprecated, will not be invoked by Java Debugger.

for the jdt:// uri, if a thrid party debugger want to get the content, they also need to support LSP protocol besides the DAP protocol, it would be really nice if we can remove this restriction :

if the uri is jdt://, we send back an sourceReference like 1 and let the dbugger get the content using the sourceRequest command

[puremourning]

and jdt content provider to open jdt://xyz uri

as @dassio says, sending a URI in the path field is a breach of the protocol when pathFormat is not uri:

  /**
   * Determines in what format paths are specified. The default is 'path', which is the native format.
   * Values: 'path', 'uri', etc.
   */
  pathFormat?: string;

It would be preferable and more portable and compliant for the DA to implement the source request and return the disassembled source that way, rather than relying on third-party integration of a DAP client and an LSP client (where there may be MxN integrations required).

Should this be raised as a new issue ?

[testforstephen]

From the perspective of integration, making the debugger to return the contents will bring some new problem. One challenge is the language features won't work in the contents returned by debugger.

Maybe we can add a switch (e.g. vmArgs=-DsourceRequest=true) to control whether to adopt the source request in the debugger.

[puremourning]

Maybe just check whether the client requested files or URIs. It's not valid to return a URI in the source path field if pathFormat is not uri. If the client requested URIs, return sourceReference 0 and the custom JDT URI, otherwise supply sourceReference and use the source request.

language features won't work in the contents returned by debugger

you mean like go-to-definition and such like ? is this somehow related to the custom "hot code reload" commands that the debug adapter/language server implement ?

In that case, maybe you could base this decision off the support for that (e.g. if the client reports a custom capability that they support your custom protocol extensions, then send your jdt:// URIs, otherwise use the source request) ? Would that work?

[testforstephen]

Maybe just check whether the client requested files or URIs. It's not valid to return a URI in the source path field if pathFormat is not uri. If the client requested URIs, return sourceReference 0 and the custom JDT URI, otherwise supply sourceReference and use the source request.

VS Code client sends pathFormat to path, but accepts customized uri format at the source.path segment. Maybe it's a VS Code bug. Unless it's fixed, otherwise we didn't want to break the current behavior for VS Code Java Debugger.

you mean like go-to-definition.

Yes, all language features such as go to definition, javadoc are supposed to work when you're actually debugging the code. That's why the debugger delegates the binary class source rendering to the language server.

[puremourning]

Ugh. de facto.

Is there some way that the vscode-java extension could indicated to you that it does this/supports this out-of-protocol behaviour? That way the default behaviour can be in-protocol ?

The problem is that outside of vscode there's no guarantee (or likelihood) that the DAP client and the LSP client are in any way related - they are totally different things. I realise that the java debugger being hosted in the language server is unique, and it requires some collusion (the 'startDebugSession' command the LSP client has to export), I would like to avoid coupling my DAP client to any one of myriad LSP clients in vim-land (and I assume the authors of other non-vscode DAP clients would agree).

[testforstephen]

I got your point, but this repo is not a standalone project.

This repo contains two components debug.core and debug.plugin.

• debug.core is neutral and reusable for others. It's used to adapt the JDI(Java Debug Interface) to the DAP protocol, and doesn't depend on any jdt logic. The advanced features such as source mapping and evaluation are delegated to the provider interfaces such as ISourceLookUpProvider and IEvaluationProvider.
• debug.plugin is an implementation of these providers based on eclipse.jdt.ls. It only works in the context of eclipse.jdt.ls. I don't think you can reuse debug.plugin separately. jdt:// and startDebugSession you mentioned all are from debug.plugin components.

If you want to keep the debugger running alone, then you must implement these provider interfaces by your own.