Higher versions of Golang will crash

[eddielth]

At that time, I was using a higher version of Golang (Version>=1.14)，when this method is executed, an error will be reported and the program will crash.
D:\go\pkg\mod\github.com\go-ole\[email protected]\oleutil\oleutil.go

func CallMethod(disp *ole.IDispatch, name string, params ...interface{}) (result *ole.VARIANT, err error) {
return disp.InvokeWithOptionalArgs(name, ole.DISPATCH_METHOD, params)
}

The panic error such as blows:
textual

• textual.color
• textual.number
• textual.random
• textual.weekday
  Exception 0xc0000005 0x0 0x566a7d10 0x1f51b1d9
  PC=0x1f51b1d9

runtime.cgocall(0x887d20, 0xd81c20)
D:/software/go/src/runtime/cgocall.go:158 +0x4a fp=0xc000129a28 sp=0xc0001299f0 pc=0x8248ea
syscall.SyscallN(0x0?, {0xc000129ac0?, 0x0?, 0xd81960?})
D:/software/go/src/runtime/syscall_windows.go:557 +0x109 fp=0xc000129aa0 sp=0xc000129a28 pc=0x882f69
syscall.Syscall9(0xc000000000?, 0x824987?, 0xc000046000?, 0xc000129bb8?, 0x882f9c?, 0x887d20?, 0xd81c20?, 0xc000129bd8?, 0x882f9c?, 0xc000129c70, ...)
D:/software/go/src/runtime/syscall_windows.go:507 +0x78 fp=0xc000129b18 sp=0xc000129aa0 pc=0x882e38
github.com/go-ole/go-ole.invoke(0x26b566a7a20, 0x6002000b, 0x1, {0xc000129db0, 0x2, 0x26b566a7a20?})
D:/go/pkg/mod/github.com/go-ole/[email protected]/idispatch_windows.go:175 +0x14e6 fp=0xc000129d00 sp=0xc000129b18 pc=0x92da66
github.com/go-ole/go-ole.(*IDispatch).Invoke(...)
D:/go/pkg/mod/github.com/go-ole/[email protected]/idispatch.go:27
github.com/go-ole/go-ole.(*IDispatch).InvokeWithOptionalArgs(0x9?, {0xb2145e?, 0x11?}, 0x94e0?, {0xc000129db0, 0x2, 0x2})
D:/go/pkg/mod/github.com/go-ole/[email protected]/idispatch.go:71 +0x85 fp=0xc000129d48 sp=0xc000129d00 pc=0x92c005
github.com/go-ole/go-ole/oleutil.CallMethod(...)
D:/go/pkg/mod/github.com/go-ole/[email protected]/oleutil/oleutil.go:51
github.com/konimarti/opc.(*AutomationItems).addSingle(0xc0000538c0, {0xc000076a20, 0xd})
D:/go/src/github.com/konimarti/opc/connection_windows.go:263 +0xb5 fp=0xc000129de0 sp=0xc000129d48 pc=0xaa6ad5
github.com/konimarti/opc.(*AutomationItems).Add(0xac94e0?, {0xc00005e400?, 0x4, 0xc000052220?})
D:/go/src/github.com/konimarti/opc/connection_windows.go:275 +0xe5 fp=0xc000129e40 sp=0xc000129de0 pc=0xaa6d05
github.com/konimarti/opc.NewConnection({0xb24e62, 0x11}, {0xc000052220, 0x1, 0x1}, {0xc00005e400, 0x4, 0x4})
D:/go/src/github.com/konimarti/opc/connection_windows.go:473 +0xcb fp=0xc000129ee8 sp=0xc000129e40 pc=0xaa84eb
main.main()
D:/go/src/github.com/konimarti/opc/example/browser.go:26 +0xd6 fp=0xc000129f80 sp=0xc000129ee8 pc=0xaa9e36
runtime.main()
D:/software/go/src/runtime/proc.go:250 +0x1fe fp=0xc000129fe0 sp=0xc000129f80 pc=0x85ba3e
runtime.goexit()
D:/software/go/src/runtime/asm_amd64.s:1594 +0x1 fp=0xc000129fe8 sp=0xc000129fe0 pc=0x886461

goroutine 2 [force gc (idle)]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
D:/software/go/src/runtime/proc.go:363 +0xd6 fp=0xc000049fb0 sp=0xc000049f90 pc=0x85bdd6
runtime.goparkunlock(...)
D:/software/go/src/runtime/proc.go:369
runtime.forcegchelper()
D:/software/go/src/runtime/proc.go:302 +0xb1 fp=0xc000049fe0 sp=0xc000049fb0 pc=0x85bc71
runtime.goexit()
D:/software/go/src/runtime/asm_amd64.s:1594 +0x1 fp=0xc000049fe8 sp=0xc000049fe0 pc=0x886461
created by runtime.init.6
D:/software/go/src/runtime/proc.go:290 +0x25

goroutine 3 [GC sweep wait]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
D:/software/go/src/runtime/proc.go:363 +0xd6 fp=0xc00004bf90 sp=0xc00004bf70 pc=0x85bdd6
runtime.goparkunlock(...)
D:/software/go/src/runtime/proc.go:369
runtime.bgsweep(0x0?)
D:/software/go/src/runtime/mgcsweep.go:278 +0x8e fp=0xc00004bfc8 sp=0xc00004bf90 pc=0x84552e
runtime.gcenable.func1()
D:/software/go/src/runtime/mgc.go:178 +0x26 fp=0xc00004bfe0 sp=0xc00004bfc8 pc=0x83a0c6
runtime.goexit()
D:/software/go/src/runtime/asm_amd64.s:1594 +0x1 fp=0xc00004bfe8 sp=0xc00004bfe0 pc=0x886461
created by runtime.gcenable
D:/software/go/src/runtime/mgc.go:178 +0x6b

[konimarti]

Thanks! Yes, I agree it's a good idea to bump the minimum go version and update the package dependencies.

However, I don't think that the error reported is related to this. I think it's a mismatch between the architecture of your OPC components and the compiled go code. Can you please test again with $ENV:GOARCH=386 (in powershell on Windows).

[eddielth]

Thanks for your answer, I am sure that I am using a 32bit environment. I have many Golang versions on my machine. When the Golang version is greater than or equal to 1.14, the above error will be reported.

When I was debugging or logging, I found that this method
_, err := oleutil.CallMethod(opcitem, "Read", OPCDevice, &v, &q, &ts) is called once,

and the method inside will be called countless times
return disp.InvokeWithOptionalArgs( name, ole.DISPATCH_METHOD, params),

it feels like it has entered an infinite loop, and then the program crashes after a while.

[konimarti]

Mhh. I can only reproduce your error when running with the wrong architecture. In your stacktrace, there's also a reference to D:/software/go/src/runtime/asm_amd64.s file, that's why I assumed you are using the wrong architecture.

I have bumped the minimum go version to 1.19 and updated all packages on the current master. Could you check out the most recent master and run go run ./cmds/opc-cli/main.go list localhost (or substitute localhost with your opc server)? If that's not succeful, please run and share the output of go env GOARCH. Thanks!

[eddielth]

Thank you for your reply.
I think you are right, the GOARCH bit i386 needs to be set so that the program can run properly.

But I still have some questions, I hope you can help answer them.

Let's unify the terminology first. We call the version using Golang 1.12 the old version, and the version based on Golang 1.19 you just updated is called the new version.

First, in the old version of the program (and the Golang I use is 1.13), I have never set GOARCH=386. In my 64-bit PC, the OPC Core Component is installed and registered using regsvr32 x64/gbda_auto.dll dll, the program can be run directly without error. When I upgraded my local Golang program to Golang1.19 (>=1.14), I had to set GOARCH=386, which can run, but cannot be debugged (because neither VsCode nor Goland support 64-bit Debug 32-bit program in the environment), of course this is not that important.

Second, when I was using a new version (my local Golang was also upgraded to 1.19), I found that the code functions were still a little different from before. I also set GOARCH=386.
Here's an example.
If you add a non-existent point to the old version of the program, the program will catch the error and return error.

func main() {
	client, err := opc.NewConnection(
		"Graybox.Simulator",
		[]string{"localhost"},
		[]string{},
	)
	defer client.Close()
	if err != nil {
		panic(err)
	}
	err = client.Add("options.sawfreqxxxxxxx")
	if err != nil {
		//a non-existent point ,
		//if using old version ,the program will catch the error and return error
		//if using new version ,the program will crash
		log.Println(err)
	}
	fmt.Println(client.ReadItem("options.sawfreqxxxxxxx"))
}

In the new version of the program, the program will report a null pointer and then panic.
The error message is as follows

panic: runtime error: invalid memory address or nil pointer dereference
         panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x0 addr=0x0 pc=0x6ad4f5]

goroutine 1 [running]:
github.com/konimarti/opc.(*AutomationItems).Close(0x1340a158)
         D:/go/src/github.com/konimarti/opc/connection_windows.go:349 +0x55
github.com/konimarti/opc.(*opcConnectionImpl).Close(0x134240f0)
         D:/go/src/github.com/konimarti/opc/connection_windows.go:462 +0x90
panic({0x6f0880, 0x9f1010})
         D:/software/go/src/runtime/panic.go:884 +0x1ba
github.com/go-ole/go-ole.(*IDispatch).VTable(...)
         D:/go/pkg/mod/github.com/go-ole/[email protected]/idispatch.go:18
github.com/go-ole/go-ole.getIDsOfName(0x0, {0x134afd88, 0x1, 0x1})
         D:/go/pkg/mod/github.com/go-ole/[email protected]/idispatch_windows.go:21 +0xec
github.com/go-ole/go-ole.(*IDispatch).GetIDsOfName(...)
         D:/go/pkg/mod/github.com/go-ole/[email protected]/idispatch.go:22
github.com/go-ole/go-ole.(*IDispatch).GetSingleIDOfName(0x0, {0x72ef28, 0x4})
         D:/go/pkg/mod/github.com/go-ole/[email protected]/idispatch.go:47 +0x5d
github.com/go-ole/go-ole.(*IDispatch).InvokeWithOptionalArgs(0x0, {0x72ef28, 0x4}, 0x1, {0x134afe74, 0x4, 0x4})
         D:/go/pkg/mod/github.com/go-ole/[email protected]/idispatch.go:63 +0x35
github.com/go-ole/go-ole/oleutil.CallMethod(...)
         D:/go/pkg/mod/github.com/go-ole/[email protected]/oleutil/oleutil.go:51
github.com/konimarti/opc.(*AutomationItems).readFromOpc(0x1340a158, 0x0)
         D:/go/src/github.com/konimarti/opc/connection_windows.go:317 +0x15e
github.com/konimarti/opc.(*opcConnectionImpl).ReadItem(0x134240f0, {0x7370a8, 0x16})
         D:/go/src/github.com/konimarti/opc/connection_windows.go:379 +0xf5
main.main()
         D:/go/src/github.com/konimarti/opc/example/connection.go:26 +0x1a1

Third,
I have a small suggestion. The IsConnected method has been implemented in connection_windows.go. Can this method be exposed in the interface?