ECONNRESET Debugging disconnected

[pepeu93]

While debugging sometimes i get this message:

Session closed for the following reasons: read ECONNRESET
Debugging disconnected. AutoHotkey script is continued.

When i try to run ANY script again, the watch window doesn't show the value of the variables anymore, hovering also stops working, then I need to close all vscode instances and open again.
Any idea why?

[zero-plusplus]

The reason for this issue is that the debugger is sending messages to the debugger even though it is exiting.

Since this is a multi-threaded issue, it is not reproducible and I have been unable to fix it.

When I released 1.10.0, I finally found the cause and fixed it, but it was not enough.

I can't promise a reliable fix, but I will add a fix to the suspicious part.

Also, the reason why you need to reboot is because the debugger adapter is not terminated properly. It should be possible to fix that as well, but no promises can be made here either.

This issue will be closed automatically after the next release, but if the issue recurs, please reopen it.

[pepeu93]

This is very annoying because you need to reopen vscode and you lose your ctrl-z history buff, and it has been happening very often.
Do you know if there's any way to 'restore' the debugger working other than closing vscode?

[zero-plusplus]

I could not find a way to reload the debug adapter. So far it seems the only way is to reopen vscode.

Did you have this issue often in 1.9.0?
Also, are you using advanced breakpoint or debug directive?

[pepeu93]

Did you have this issue often in 1.9.0?

Yes often, it always happens after a while paused in a breakpoint.

[zero-plusplus]

Yes often, it always happens after a while paused in a breakpoint.

So it may be a different issue than what I am aware of.

I'll think about it after I release the current fix for now.

[pepeu93]

Also, are you using advanced breakpoint or debug directive?

This is my settings:

	"folders": [],
	"launch": {
		"version": "0.2.0",
		"configurations": [
			{
				"name": "Debugger",
				"type": "autohotkey",
				"request": "launch",
				"program": "${file}",
				"port": "9002-9010",
				"usePerfTips": true,
				"useAutoJumpToError": true,
				"useDebugDirective": true
			},

Let me know if you need help testing something!

[zero-plusplus]

Yes often, it always happens after a while paused in a breakpoint.

Did you set a condition for the breakpoint at this time?
Also, have you been getting any error messages by MessageBox from AutoHotkey?

Let me know if you need help testing something!

Thanks.

I will work on the release as soon as I get time. After that, please check to see if the issue recurs.

[pepeu93]

Did you set a condition for the breakpoint at this time?

No, i rarely use condition, it always happened with a normal breakpoint.

Also, have you been getting any error messages by MessageBox from AutoHotkey?

Yes, I always get a MessageBox, if I do something in my code that crashes the scripts, it's 100% of chance to get:

Session closed for the following reasons: read ECONNRESET
Debugging disconnected. AutoHotkey script is continued.

And then the debugger watch/hover variables don't work anymore.

[zero-plusplus]

No, i rarely use condition, it always happened with a normal breakpoint.

Yes, I always get a MessageBox, if I do something in my code that crashes the scripts, it's 100% of chance to get:

If the MessageBox shows up, then it seems to be the same issue I am seeing.

Do you remember the contents of the MessageBox? In my case, I get an error about infinite recursion.

If it appears, you can copy the contents by pressing Ctrl +c.

Also, is it reproducible?
It will be easier to solve the issue if a minimal script that always generates an ECONNRESET is provided.

[zero-plusplus]

The code that causes this issue.

; for AutoHotkey v2
c := A().b

class A
{
  b {
    get  {
      return this.b
    }
  }
}

[pepeu93]

Your function doesn't run:

 ==> Call to nonexistent function.
     Specifically: A().b

[zero-plusplus]

Sorry, The above example is for AutoHotkey v2.

The above code helped me to identify the cause of the issue, which allowed me to fix this issue completely.

I will release a fixed version as soon as I finish the verification process.

[pepeu93]

Glad to hear it, will you release the fix soon? I'm getting ECONNRESET with frequency.

Also, after v2 be released you will continue to support v1?

[zero-plusplus]

The debugger is basically the same regardless of version, so it should be fixed in v1 as well.

However, I have not been able to find any reproducible code in v1, so I have not been able to confirm this.

If I can find the time, the release will be done in a few days.

[zero-plusplus]

I've just released it.
It will be available for download as soon as the marketplace validation process is complete.

If you encounter this issue again, please reopen this issue or create a new one.

Thanks for the report.

[pepeu93]

Where did you call Reload in your example?

I meant reload of VSCode, not the script, like when you use the shortcut CTRL+SHIFT+P:

To share the position where you want to break, add useDebugDirective to launch.json, and add the following code to the line you want to break.
; @Debug-Breakpoint

So I should not set a breakpoint by clicking in the VSCode line? Is it just to check if still will cause the issue?

[zero-plusplus]

I meant reload of VSCode, not the script, like when you use the shortcut CTRL+SHIFT+P:

I understood.

So I should not set a breakpoint by clicking in the VSCode line? Is it just to check if still will cause the issue?

It is recommended that you use the debug directive when sharing issues.
This is because the UI configuration cannot be shared.

Also, please check if the issue still occurs when you break with debug directive.
This will make it easier for me to check.

[pepeu93]

Also, please check if the issue still occurs when you break with debug directive.

I confirmed that it still occurs using the debug directive.

[zero-plusplus]

I confirmed that it still occurs using the debug directive.

OK. Please restate the source code using the debug directive.

---

Come to think of it, I was looking at your example, I was thinking, does this error occur in scripts that use the Gui command?

I don't debug scripts that use Gui commands very often, so I may not have encountered this error easily.

[pepeu93]

I was thinking, does this error occur in scripts that use the Gui command?

What do you mean by scripts that use the Gui command?

I noticed one thing now, remember that I said sometimes it launches the script but never starts and keeps on memory forever, and even restarting multiple times it doesn't launch, then I need to reopen VSCode to it start working again?

If I remove all breakpoints from the script then it does launch, it i set a breakpoint and try launch again, then the problem return 🤕

[zero-plusplus]

What do you mean by scripts that use the Gui command?

This means the AutoHotkey Gui command.

I noticed one thing now, remember that I said sometimes it launches the script but never starts and keeps on memory forever, and even restarting multiple times it doesn't launch, then I need to reopen VSCode to it start working again?

Are you referring to this issue?
Please post the information about the issue there. Also, please repost this information there as well.

The two topics are currently mixed up and it is difficult to tell which information is about which.
I am particularly affected by this because I use translation.

So please try to keep it to one topic per issue.

[zero-plusplus]

This is very annoying because you need to reopen vscode and you lose your ctrl-z history buff, and it has been happening very often.
Do you know if there's any way to 'restore' the debugger working other than closing vscode?

I have looked for a workaround for the above issue, but it seems that this part is part of the core of VSCode and cannot be solved by extensions, etc.

Sorry for not being able to help you.

I plan to restructure the debugger in the future, but it will be a year at the earliest as I am currently focusing on creating an AutoHotkey parser and then extension to assist in the development of AutoHotkey.

However, I should be able to fix the issue as soon as I can find a way to reliably reproduce the issue.

[pepeu93]

Thank you!
I started testing the new version you released, and ill give feedback if these current issues persist.

[zero-plusplus]

OK.

If I come up with an idea to solve this issue, I will work on this branch.

[pepeu93]

I have been using the newer version since release, all the issues remain the same :(.

[zero-plusplus]

Thanks for confirming.

Can you confirm if the same issue occurs with the Windows SandBox test described below link?

#197 (comment)

[pepeu93]

I cant because I don't have windows pro, sandbox is available only in the Pro version.
I tested on 3 different computers (v1.11.0) and in all, I keep getting this issue of ECONNRESET.

you can clone the master branch of this repository

Does the master branch has something different from the current version that's on the marketplace?

[zero-plusplus]

I cant because I don't have windows pro

I understand.

What version of AutoHotkey.exe are you using?

Does the master branch has something different from the current version that's on the marketplace?

No difference.
Don't worry about it, as the instruction is for testing in the sandbox.

[pepeu93]

AutoHotkey Unicode 64-bit (1.1.33.10)

[zero-plusplus]

I assume that this issue is caused by the debugger's command being executed after debugging has been disconnected.

Since the timing of the issue seems to be when the script is stopped by a breakpoint, I was thinking that the command to the debugger is failing for some reason.
However, since the debugger's command is stable in v1 and I have not experienced any debug disconnects due to command execution, my guess may be wrong.

In other words, I do not know the cause of the issue at this time.

[pepeu93]

Today i got the message without being paused on a breakpoint, it happened after I clicked in the line before Time := (A_TickCount - Time) and pressed enter.

   Time := (A_TickCount - Time)
   If (Time < 1000)
      Sleep, 600

[zero-plusplus]

Today i got the message without being paused on a breakpoint, it happened after I clicked in the line before Time := (A_TickCount - Time) and pressed enter.

What did you click?

This issue occurs not only when the script is stopped by a breakpoint, but also when the script is stopped by step execution, etc.

[pepeu93]

I clicked in the line before Time := and pressed enter to add a new empty line, then at this time i got the bug message, i was thinking it was caused by the new line entered in the script

[zero-plusplus]

I don't understand how the issue could occur at that timing.
I actually tried it and it never sent any commands to the debugger.

I considered the possibility that the issue occurred because the IntelliSense was executed and the command was sent to the debugger, but pressing the Enter key did not execute the IntelliSense nor did it send the command.

In other words, I do not know why this issue occurred at that time.

[zero-plusplus]

I will not be using discord as I want to keep all records on GitHub.
If you want to share your screen, please upload images or videos to GitHub.

[pepeu93]

I confirmed that the issue is being caused because of modifications I did on the source of the AutoHotkey, I'm closing the issue as the extension is not causing it.

[zero-plusplus]

OK.
Never mind, thanks for the confirmation work.

Please let me know if there are any more issues.

[gildahl]

Just a note that I am in the process of porting an AHK 1.1 program into AHK 2 and just started running into this problem as well (I have not done any mods to AHK source). I'm having a lot of trouble tracing the exact part of my code that is causing this since it seems unrelated to breakpoints (it happens even I I have none, and seemingly at random times). I do spin off a lot of threads so might be something there. Anyway, I'll update if I can get to something specific, but just curious as to whether there has been any recent attention to this issue?

[zero-plusplus]

This problem is not reproducible and I do not know for what reason the communication error with the debugger is occurring.

After this problem can you successfully start debugging again?
Or will debugging not work until I restart vscode?

The above problem may be fixed by a fix here.

[gildahl]

Generally, just restarting the debug session works. I did have some cases in which I had to actually reboot. If I can narrow things down to an exact cause, I'll update. The code is something like 20,000 lines with quite a few threads and I know as part of the conversion, I'm running into memory write issues all over the place (which are usually picked up by the debugger), but it wouldn't surprise me if one of them is going undetected and killing the process. That's only a guess though at this point. In either case, I'd be lost without this tool, so I'm still extremely thankful for it!

[zero-plusplus]

Thank you!
I will re-open this issue so any information would be appreciated here.

---

Errors in memory writes were discussed in the following issue.

• [bug] Critical Error: Invalid memory read/write #26
• Error occurs when getting dynamic properties by data inspect, etc #51

[gildahl]

Well I managed to eliminate at least one case of the ECONNRESET error which turned-out to be occurring whenever I destroyed one of my Gui windows. Since destroying other windows didn't do this, I looked more critically at the code. There's a ListView owned by the window that acts as a user interface, and it contains a hidden column in which I store the addresses of Map elements using ObjPtrAddRef(). When a user scrolls to a row, the address is read as text then converted back into an object using ObjFromPtr() to fill in various screen elements. What I was not aware of is that reading this back decrements the internal reference counter so I was ending up with invalid memory references when trying to pull the object out a second time. It was under these kinds of conditions that the ECONNRESET would occur. The fix was to use ObjFromPtrAddRef() instead of ObjFromPtr(), but it looks like these sort of bugs are at least one of the things that can cause the ECONNRESET.

[zero-plusplus]

Thanks for the info.

It seems that ECONNRESET is caused by a problem on the server side.
Therefore, if it is caused by a reference counter or memory operation error, it is a debugger specification and I may not be able to help you.

[gildahl]

Not a problem. Now that I have a better idea of the sort of conditions that can lead to this I can deal with it. It might be cool if you had the ability to specify the last line of code executed prior to the reset, but beyond that I can see why there probably isn't much you can do about it.

[zero-plusplus]

I am relieved that there was a way to deal with it. I will therefore close this issue again.

It might be cool if you had the ability to specify the last line of code executed prior to the reset, but beyond that I can see why there probably isn't much you can do about it.

Since it is not possible to identify at what point the error occurred or not, it would be difficult to fulfill that request.

Conversely, if it is known at what point the error occurred, it is possible to restore the state. (Not possible in the case of ECONNRESET...)

In the past, this was impossible due to the specification, so it was given up. Recently, however, the debugger supports exception breakpoints, so it is now possible to determine at what point an error occurred or not.

If there is demand, I may implement it.