When a debug adapter crashes, the exception text is not propagated to the console

[DanTup]

I've had a couple of people report debug adapter crashes recently. One of them I'm unable to reproduce which means I need to get more information from the user. Currently, when a debug adapter crashes, the error information that appears in the console is very vague:

The actual exception that was thrown is not shown. Since I can't repro this, the only ways I can think of to debug are:

1. Add try/catch around all debugger methods that handles errors and passes them back nicely (and remember to do this for all future methods)
2. Get the user to run my project from source and debug the debug adapter to catch the error (whilst not the hardest thing in the world, it's a bit involved for an end user)

Is it possible to get better information from the error back into the console without having a debugger attached to debug adapter?

[DanTup]

I don't know if the text "ERR" in the console was actually supposed to be my error; but it isn't. My error was "AAAAAARGH".

[isidorn]

@DanTup this request makes sense.
Not sure though if I am getting your error when your process crashes. Can you be so kind and set a breakpoint here make your server crash and check if your message is coming through as a signal or as something else.

Thanks

[DanTup]

@isidorn Do you mean the ERR text? I also don't get that now when trying to repro, only the "terminated unexpectedly" message.

If you still want me to try that breakpoint, can you explain how to add a breakpoint there. I did try breaking in my adapter and navigating the callstack (that file wasn't in there anywhere) and also checking the filenames of the files that were (they showed <node internals>).

[isidorn]

@DanTup I mean let's try to see if your error "AAAAARGH" surfaces on our side.
You should be able to just run regular vscode, F1 > open developer tools, wait some time and put a breakpoint by openning a rawDebugSession.ts.
Also try to put a breakpoint here and check if the error stream spits up something.

[ncannasse]

The breakpoint is not hit, which is perfectly normal since the exception occurs before the socket connection is created. You should be able to reproduce by adding require('unknown_module') to the top of any debugger extension .js file

[DanTup]

Ok, I got breakpoints in both onServerError and onServerExit. First wasn't called and the second was called but code is 1 and signal is null. So seems like the message isn't there.

For testing, all I've done is put throw "AAAAARGH"; inside my debug adapter.

Though now I think about it; the error isn't occurring in code that's been executed directly by Code - it's during the response from my debugger. In my debug adapter I spawn a process and I add a handler for stdout. When something comes over stdout and my callback runs, that's where the crash is occurring. I don't know if this changes things (for example, I don't know if this is on another thread?).

[DanTup]

Also try to put a breakpoint here and check if the error stream spits up something.

That one (in connectServer) didn't seem to be hit either.

[DanTup]

Actually, I think I can repro this really easily by just putting throw "test"; in the constructor of the DebugSession? Also gets code=1, signal=null.

export class DartDebugSession extends DebugSession {
	public constructor() {
		super();
		throw "test";
	}

[DanTup]

@isidorn This issue has the needs-more-info tag though I think it's easily reproducible with my last comment. Let me know if that's not the case!

[isidorn]

@DanTup I have removed tha tag and plan to look into this issue this week. Thanks

[isidorn]

Investigated and the issue here is that I am not getting any exception data from the spawned process.
I simply get the exit code here while all the other error chanels are blank. I am not sure what would be the proper solution here.
Suggestions are very welcome. Also @weinand @bpasero

@DanTup @ncannasse are all your debug adapters launched using node? If yes then it might be that our stdFork launch is somehow eating up the error if it happens on startup.
If this also happens for adapters which are not realying on node to be launched then stdFork is not to blame.

[weinand]

@isidorn please try to disable the stdfork launch for node (here) and see whether this makes a difference. DAs should work independent from stdfork. But make sure that the node version used is roughly the same as Electron's version (i.e. 7.9.0).

[isidorn]

Yes, using stdfork is the cause here. If I do not use it, I nicely get the error popping up in the extensions output channel.

My weekend is starting if someone is feeling smart code review this file and let me know if you find something fishy about stderr not being wired through.

[weinand]

Then you might want to involve/assign @alexandrudima.

[isidorn]

I am going on a vacation tomorrow evening, and this is like this since forever so pushing to April to investigate with Alex what is going on behind the curatans here.