Incidental null pointer when turning on debug mode

[PaulKlint]

Describe the bug

After typing :set debugging true in the REPL, the expected behavior is to stay in the REPL window and debugging mode is turned on. Usually this works fine. From time to time the following happens:

• The REPL window looses focus.
• The below stack trace is printed in the REPL.

Stack traces

rascal>Jan 03, 2026 1:10:21 PM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint fallbackResponseError
SEVERE: Internal error: null
java.lang.UnsupportedOperationException
        at org.eclipse.lsp4j.debug.services.IDebugProtocolServer.source(IDebugProtocolServer.java:551)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at org.eclipse.lsp4j.jsonrpc.services.GenericEndpoint.lambda$recursiveFindRpcMethods$0(GenericEndpoint.java:65)
        at org.eclipse.lsp4j.jsonrpc.services.GenericEndpoint.request(GenericEndpoint.java:128)
        at org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.handleRequest(RemoteEndpoint.java:271)
        at org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.consume(RemoteEndpoint.java:201)
        at org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer.handleMessage(StreamMessageProducer.java:185)
        at org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer.listen(StreamMessageProducer.java:97)
        at org.eclipse.lsp4j.jsonrpc.json.ConcurrentMessageProcessor.run(ConcurrentMessageProcessor.java:114)
        at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
        at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
        at java.base/java.lang.Thread.run(Thread.java:829)

Desktop (please complete the following information):

• Context: VS Code extension, 0.13.0

[DavyLandman]

@jbdoderlein could you take a peek?

[jbdoderlein]

I did not succeed to replicate the bug for the null pointer exception. I don't know if this is related to the issue, but on opening debug session in VSCode, the default is that VSCode focus on the Debug Console panel.
This behavior can be changed with the option "debug.internalConsoleOptions": "neverOpen". I don't know if this option can be set automatically for Rascal DAP by the VSCode extension

[DavyLandman]

@jbdoderlein looking at the stacktrace, I think that our RascalDebugAdapter should implement the source callback?

https://github.com/eclipse-lsp4j/lsp4j/blob/1ec37d8a363bd3e46830e3899072ba49cb75abd9/org.eclipse.lsp4j.debug/src/main/java/org/eclipse/lsp4j/debug/services/IDebugProtocolServer.java#L547-L553

[jbdoderlein]

This is very strange. It seems like VSCode called the source request to DAP, but it is not supposed to.
From specification, content is retrieved from source request if sourceReference>0, and path is used otherwise.
The only place we generate Source is in stackTrace request, and we put every sourceReference to -1.

If we want to comply with the specification, we should maybe unset this field or put it to 0 :

[path] is only used to locate and load the content of the source if no sourceReference is specified (or its value is 0).

But overall this bug look like a VSCode bug.

[DavyLandman]

hmm, yeah maybe it's better to put a 0 in sourceReference? as -1 is not a documented sentinel value?

[jbdoderlein]

Yes, an additional modification could also be to implement the endpoint as an error with a pretty print of the request.If this error happens again, we can know which resource was asked through this request.