Crashed on script start #1433
Comments
|
I am noticing massive problems with this update. Yesterday I was using 1.8.0 with absolutely no issues. Today, VS Code installed 1.8.1 automatically and I've had nothing but problems. Long terminal start times, long debugging times, frequent crashes... at one point I tried logging out of Windows thinking there was a process hanging somewhere. The slowdowns and crashes happen even with the simplest of scripts. |
|
Hi @nathan-alden-hp, would you be able to provide more information about your environment? The following would be helpful in diagnosing the problem:
|
OS: Windows 10 Enterprise 1803 I can't get you extension logs at the moment. VS Code was upgraded to the version I just posted after I submitted my original comment. It seems more stable now, so I'll keep an eye on it. |
|
Okie doke, no worries. That sounds positive, but please do open an issue if you have any problems. And thanks for uploading that info too! |
|
@PrzemyslawKlys the logs you attached indicate the extension is failing right after a debug session has been started. This is happening within 4 secs of the extension starting up PSES. What exactly are you repro steps? I see you listed:
But I'm not sure how any of that would initiate a debug session. |
|
@rkeithhill I may have pressed F5... however keep in mind that I've switched F5 with CTRL+F5 just for this reason. And even thou I don't use debugging at all. I am constantly getting VSCode hanging with that debugging in place. I am not sure where is it coming from.
I get VSCode to hang quite often for no reason. |
|
@PrzemyslawKlys Thanks. With that, I can reproduce this. The twist is that you are attempting to "run" the script before the PS editor (and debug) services (PSES) has fully initialized. To avoid this for now, wait until this message in the status bar:
changes to:
... before attempting to start or debug a script. Initialization can take ~5-10 seconds for the PSES to fully initialize. In the meantime, we'll be looking for ways to prevent run/launch from VSCode until PSES is initialized. |
|
Great! I guess I am just impatient. Maybe I don’t know how to properly debug scripts in powershell and i essentially press f5 get errors/output, fix things, rerun and so on. |
|
@tylerl0706 @rjmholt Debugged this to this line: public Task SendEvent<TParams, TRegistrationOptions>(
NotificationType<TParams, TRegistrationOptions> eventType,
TParams eventParams)
{
// Some requests may still be in the SynchronizationContext queue
// after the server stops so don't act on those requests because
// the protocol channel will already be disposed
if (this.currentState == ProtocolEndpointState.Shutdown)
{
return Task.FromResult(true);
}
// Some events could be raised from a different thread.
// To ensure that messages are written serially, dispatch
// dispatch the SendEvent call to the message loop thread.
if (!this.InMessageLoopThread)
{
TaskCompletionSource<bool> writeTask = new TaskCompletionSource<bool>();
this.SynchronizationContext.Post( <<<<===== SynchronizationContext is null at this point
async (obj) =>
{
await this.protocolChannel.MessageWriter.WriteEvent(
eventType,
eventParams);
writeTask.SetResult(true);
}, null);
return writeTask.Task;
}This is happening because VSCode, seeing that the extension has been activated, allows run/debug session to be started before PSES is fully initialized. |
|
I have one attempt fix in the extension where we pop a warning dialog if the user attempts to debug/run a script before PSES has finished initializing. The result is this warning notification: edit: s/starting up/starting/ The one downside to this approach is that VSCode opens Ideally, we could either indicate to VSCode that our debugger isn't ready yet OR during the |
Fix #1433 One minor issue is that if you abort (return null|undefined) from resolveDebugConfiguration, VSCode "helpfully" opens your launch.json file for you. Actually, that is quite annoying. I found an issue and on this and voted it up - microsoft/vscode#54213 Also fix logic for "attach" error. We only need to test if OS != Windows. If on Windows, PS Core supports attach. And tweaked the error message wording to make more clear. If the user attempts to start a dgb or "run with out debugging" session before PSES is running, a NullRefEx occurs in PSES. Ideally, we would wait in the resolveDebugConfiguration method for PSES to finish initializing with a max wait time of say 10 seconds. Unfortunately, "sleep" in a loop in JavaScript is not so easy. AFAIT requires a significant rewrite of the method using setTimeout(). Not sure it is worth it, unless someone more knowledgable in JS can find an easy way to do the poll (for sessionstatus)/sleep loop. BTW there is probably a fix we need to make in PSES to check if SynchronizationContext is not null before we try to use it.
|
I'd rather just indicate that it's not ready yet. I think that's a reasonable approach/response considering it's rare people run into this. I also really like the words on that warning! |
|
Awesome investigation, Keith! |
…1436) Fix #1433 One minor issue is that if you abort (return null|undefined) from resolveDebugConfiguration, VSCode "helpfully" opens your launch.json file for you. Actually, that is quite annoying. I found an issue and on this and voted it up - microsoft/vscode#54213 Also fix logic for "attach" error. We only need to test if OS != Windows. If on Windows, PS Core supports attach. And tweaked the error message wording to make more clear. If the user attempts to start a dgb or "run with out debugging" session before PSES is running, a NullRefEx occurs in PSES. Ideally, we would wait in the resolveDebugConfiguration method for PSES to finish initializing with a max wait time of say 10 seconds. Unfortunately, "sleep" in a loop in JavaScript is not so easy. AFAIT requires a significant rewrite of the method using setTimeout(). Not sure it is worth it, unless someone more knowledgable in JS can find an easy way to do the poll (for sessionstatus)/sleep loop. BTW there is probably a fix we need to make in PSES to check if SynchronizationContext is not null before we try to use it.
System Details
$PSVersionTable:Issue Description
I am experiencing a problem with... crashing of PowerShell Extension. Copied script from internet. Pasted. Saved. Crashed.
Attached Logs
EditorServices.zip
The text was updated successfully, but these errors were encountered: