Open ghost opened 3 years ago
@paitkenhead I just googled for 0x406d1388 and find
https://github.com/go-delve/delve/issues/1383
Which explains what your problem is. And the issue also lists the fix for Delve
https://github.com/go-delve/delve/pull/1384
I assume you use Delve to debug your programs - I don't really know, I don't use vs code
(whatever that is).
If you do use recent version of Delve, then you should not see this crash. Maybe you use old version of Delve. Maybe your vs code
is misconfigured in some way. Do you know where Delve is installed on your computer? If yes, maybe try and run Delve from command line and see if it still crashes.
Alex
@alexbrainman my confusion comes from the fact that it works fine as long as it is in debugging mode, but won't work outside of debugger.
VS Code (Virtual Studio Code) uses delve for debugging behind the scenes, and when I start debugging mode in VS Code it runs without issues.
Similarly, when I run using delve from command line the code runs fine (as per the output above).
The exception is only throw when not in debugging mode. i.e. when running using RUN GO, or when using the .EXE.
The exception is only throw when not in debugging mode. i.e. when running using RUN GO, or when using the .EXE.
Thanks for explaining. I did not realized what is happening.
I was under expression that sending 0x406d1388 can only happens if you process is debugged. But your process is getting this exception even when it is not debugged.
Perhaps you get exception even when in debugger. But, if you are using modern version of Delve, Delve captures and ignores this exception for you.
Whole concept of setting thread name only makes sense while debugging. Because no one can see thread names when process runs without debugger attached.
But it appears some DLL that your program loads (perhaps DLLs for 4d ODBC driver) raises this exception.
The only way to ignore this exception that I know of is to add this exception to runtime
and rebuild Go itself.
Maybe you can report this problem to the driver developers, and they will adjust their code. This is a bug as far as I am concerned. It is OK to raise this exception when debugged, but not when there is no debugger running.
Alex
Thanks so much @alexbrainman for checking it out. I'll see how I go rebuilding Go to workaround, but I'll also report the bug with 4D. Love your work!
Paul
Just for the sake of information, I have just tried using the 4Dv18 ODBC Driver and it behaves in the same manner (ie. works in debug mode, but throws exception when run outside of debug mode).
Perhaps related to Issue 134.
I'm trying to use the 4D v17 ODBC Driver 64-bit on Windows 10, and while I can connect and ping successfully when running within VS Code using "Run/Start Debugging", when I try using "Run/Run Without Debugging" it fails. I get the same failure when I try using GO RUN, or running the .EXE.
OUTPUT IF RUN USING "START DEBUGGING"
OUTPUT IF RUN USING "RUN WITHOUT DEBUGGING" or GO RUN or .EXE
I'm perplexed. I imagine it must have something to do with the ENV but can't figure out what. Regards, Paul