4d ODBC Driver - works in vs code debug mode, but not otherwise

[ghost]

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.

package main

import (
    "database/sql"
    "fmt"
    _ "reflect"

    _ "github.com/alexbrainman/odbc"
)

func main() {

    db, err := sql.Open("odbc", "DSN=Genie")
    if err != nil {
        fmt.Println("Connection Failed :( ", err)
    } else {
        fmt.Println("Can Connect :)")
    }
    defer db.Close()

    err = db.Ping()
    if err != nil {
        fmt.Println("Ping Failed :( ", err)
    } else {
        fmt.Println("Can Ping :)")
    }
}

OUTPUT IF RUN USING "START DEBUGGING"

API server listening at: 127.0.0.1:22639 Can Connect :) Can Ping :) Process exiting with code: 0

OUTPUT IF RUN USING "RUN WITHOUT DEBUGGING" or GO RUN or .EXE

Can Connect :) Exception 0x406d1388 0x1000 0x1800ad640 0x7ffa24944c48 PC=0x7ffa24944c48

syscall.Syscall9(0x7ffa081c4190, 0x8, 0x234ef7d7230, 0x0, 0xc0000104e0, 0xfffffffffffffffd, 0x0, 0x0, 0x0, 0x0, ...) c:/go/src/runtime/syscall_windows.go:214 +0xf2 github.com/alexbrainman/odbc/api.SQLDriverConnect(0x234ef7d7230, 0x0, 0xc0000104e0, 0xc00001fffd, 0x0, 0x0, 0x0, 0x0, 0xa) C:/Users/paul.admin/go/src/github.com/alexbrainman/odbc/api/zapi_windows.go:108 +0x125 github.com/alexbrainman/odbc.(Driver).Open(0x1013280, 0xf54ea0, 0x9, 0x0, 0x0, 0x0, 0x0) C:/Users/paul.admin/go/src/github.com/alexbrainman/odbc/conn.go:38 +0x1bd database/sql.dsnConnector.Connect(...) c:/go/src/database/sql/sql.go:707 database/sql.(DB).conn(0xc000052dd0, 0xf7bbe0, 0xc000012048, 0xc00007fe01, 0xeffb1e, 0xc000052ea0, 0xc000012160) c:/go/src/database/sql/sql.go:1294 +0x214 database/sql.(DB).PingContext(0xc000052dd0, 0xf7bbe0, 0xc000012048, 0x1, 0x1) c:/go/src/database/sql/sql.go:799 +0x9f database/sql.(DB).Ping(...) c:/go/src/database/sql/sql.go:817 main.main() C:/Users/paul.admin/go/src/goodbc/goodbc.go:21 +0x156

goroutine 6 [select]: database/sql.(*DB).connectionOpener(0xc000052dd0, 0xf7bba0, 0xc000046040) c:/go/src/database/sql/sql.go:1126 +0xf5 created by database/sql.OpenDB c:/go/src/database/sql/sql.go:740 +0x132 rax 0x0 rbx 0x234ef52abd0 rcx 0x0 rdi 0x234ef544df0 rsi 0x1800e3ae0 rbp 0xfd2fdfd980 rsp 0xfd2fdfd690 r8 0x1 r9 0x1e r10 0x234ef544de0 r11 0x0 r12 0x601 r13 0x0 r14 0x1800a4128 r15 0x1800a95c8 rip 0x7ffa24944c48 rflags 0x206 cs 0x33 fs 0x53 gs 0x2b

I'm perplexed. I imagine it must have something to do with the ENV but can't figure out what. Regards, Paul

[alexbrainman]

@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

[ghost]

@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.

[alexbrainman]

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

https://github.com/golang/go/blob/e1b305af028544e00a22c905e68049c98c10a1cc/src/runtime/signal_windows.go#L82

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

[ghost]

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

[ghost]

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).