Re: [go-nuts] Memory corruption with GOGC=on

Sorry for taking a while to reply and, thank you very much!!! After testing over and over again this morning, the errors are gone, including the bad errors in Does gc hate me? What I got in the stacktrace is only about gc and run

Re: [go-nuts] Memory corruption with GOGC=on

2019. február 25., hétfő 10:18:42 UTC+1 időpontban yang...@gmail.com a következőt írta: > > I'm sorry for the missed detail of Receive() function. Variable gReceive > (sorry > for the silly variable name) will be manipulated in Go, since some data > coversions in the latter loop. > > Function

Re: [go-nuts] Memory corruption with GOGC=on

I'm sorry for the missed detail of Receive() function. Variable gReceive (sorry for the silly variable name) will be manipulated in Go, since some data coversions in the latter loop. Function Receive(): func Receive( devType int, devIndex int, canIndex int, pReceive []CanObj, waitTime int, ) (c

Re: [go-nuts] Memory corruption with GOGC=on

2019. február 25., hétfő 9:10:19 UTC+1 időpontban yang...@gmail.com a következőt írta: > > Thank you! > > There is a pointer copied between Go and Cgo indeed, i.e., Go creates a > slice (pReceive) to Cgo, which reads data into it. It would be reasonable > when there are some panics occurred th

Re: [go-nuts] Memory corruption with GOGC=on

Thank you! There is a pointer copied between Go and Cgo indeed, i.e., Go creates a slice (pReceive) to Cgo, which reads data into it. It would be reasonable when there are some panics occurred there. Actually, what triggers the panic is the make-slice statements, i.e., cReceive := make([]C.str

Re: [go-nuts] Memory corruption with GOGC=on

With GC off the free will not be called, nor will destructors be executed in response to finalizers, so many memory corruption errors will not be experienced (nor detected). Almost certainly the C memory is not being managed correctly - possibly copying a pointer between structs and then freein

[go-nuts] Memory corruption with GOGC=on

HI all, Error unexpected fault address might be triggered by data race or memory corruption. After code review, I suspected the reasin is memory corruption instead of the data race. The following code panics occasionally, and yes, when I initialized silces. package controlcan import "C" cRec