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

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

Clone and build the google closure compiler at https://github.com/google/closure-compiler
Set a breakpoint at src/com/google/javascript/jscomp/PeepholeCollectPropertyAssignments.java
Build the project using maven (instruction included at the front page of the repo)
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:

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.
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.
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.

Andrew Au (@cshung)

Andrew Au (@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.

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.

log.txt

"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?

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.

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.

Andrew Au (@cshung)

Andrew Au (@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

xiangbin li (@dassio)

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

as xiangbin li (@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 ?

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.

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?

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.

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).

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.

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

this seems like an easier way without breaking or the need of synchronizing with the vscode-java project

Ben Jackson (@puremourning)

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

i don't think this is what Ben Jackson (@puremourning) means, vscode is running vscode-java(LSP client) and vscode-java-debug(DAP client) together, Ben Jackson (@puremourning) only want to run the vscode-java-debug alone without the LSP client(vscode-java).

it is fine to have the debug.core and debug-plugin running together as the DAP server

well sure, if the best we can get is a command line argument when starting jdt.ls, then I guess we can ask the LSP client authors to work with that. There's already enough hacking to ask the LSP client to start the debug adapter and provide a port.

Would it be possible for the startDebugSession to take some sort of argument, rather than a command line option?

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

I feel like if I have to implement custom java processes as a DAP client author, that sort of defeats the purpose of having debug adapters implement a common protocol in the first place. Unfortunately I find myself in the 'one person in their spare time with a full time job' OSS world supporting vimspector and I would thoroughly like to leverage the great stuff that's being provided here and from jdt.ls in a way which doesn't mean a job for life just maintaining support for one adapter.

Thank you for all the recent activities on this PR. This was 493 days ago, I already forgot what I did. I think I was experimenting with the closure compiler just to realize the debugger wasn't quite working as I expected, so I dug and 'fixed' it just to realize a very simple workaround existed for me.

Let me know if there is something I can contribute on, I would be happy to do so.

Andrew Au (@cshung)

Hi Andrew Au (@cshung), I'm an AI Support assistant here to help with your issue. While the team reviews your request, I wanted to provide some possible tips and documentation that might help you in the meantime.

The error you’re seeing is tracked in the upstream Java debug extension repository:

• Duplicate issue: microsoft/vscode-java-debug#550

No fix has been merged yet. Your proposed PR to assign a non-zero sourceReference in StackTraceRequestHandler.convertDebuggerSourceToClient and register it in DebugAdapterContext is the right approach. Please follow the discussion on the duplicate issue and update to the latest vscode-java-debug once a fix is released.

The team will respond to your issue shortly. I hope these suggestions are helpful in the meantime. If this comment helped you, please give it a 👍. If the suggestion was not helpful or incorrect, please give it a 👎. Your feedback helps us improve!

Navigation Menu

Repository navigation

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

Environment

Steps To Reproduce

Current Result

Expected Result

Additional Information

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Environment

Steps To Reproduce

Current Result

Expected Result

Additional Information

Activity

testforstephen commented on Mar 18, 2019

testforstephen commented on Mar 18, 2019

cshung commented on Mar 18, 2019

testforstephen commented on Mar 18, 2019

cshung commented on Mar 18, 2019

testforstephen commented on Mar 19, 2019

dassio commented on Sep 18, 2020

puremourning commented on Sep 19, 2020

testforstephen commented on Sep 21, 2020

puremourning commented on Sep 21, 2020

testforstephen commented on Sep 21, 2020

puremourning commented on Sep 21, 2020

testforstephen commented on Sep 21, 2020

dassio commented on Sep 21, 2020

dassio commented on Sep 21, 2020

puremourning commented on Sep 21, 2020

cshung commented on Sep 21, 2020

github-actions commented on Nov 14, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions