Unfortunately, after fitting the code with KeepAlive() calls (some probably superfluous), the issues and their frequency have not notably changed. It did allow me to remove the hack I had put in LockST() described in my original note though. I've even gone as far as commenting out the finalizers, which because of the flavor of the interface being used, probably won't leave much if any C memory stranded but is not the way we would want it in production. However it is fine for a test. Even with the finalizers out of the way, the issues remain.
Is there something else I can try to isolate this (msan and race have not been fruitful)? Note our C code has some memory sanity options in it too - we have a storage manager in it that on request will over-allocate all requests placing the requested storage in the middle, then back-filling all but the requested storage with 0xdeadbeef values with the entire storage chain having their backfills verified on every storage invocation. That too is running clean. Also, the first thing our C code does when it gets control is take out a lock because our C code is not (yet) multi-threaded so that part is single-threaded. Steve On Wednesday, May 22, 2019 at 9:29:07 PM UTC-4, Ian Lance Taylor wrote: > > On Wed, May 22, 2019 at 8:34 PM Steven Estes <est...@yottadb.com > <javascript:>> wrote: > > > > At this point, it seems, since there were no more references to the > passed-in Golang structures and the C pointers we had pulled out of them > had been morphed to uintptr values, that the Golang structures became > eligible for garbage collection. But because there was a Finalizer set for > these structures, the C storage was released when we were not finished with > it yet – in fact had not even made the call yet to the C routine. > > > > We got errors in the C code and saw that though the structures were > well-formed in the Go routine, the stuff that ended up being passed in was > complete garbage. > > > > We “fixed” this issue by putting a meaningless reference to the golang > variadic list that held all these values just prior to returning from the > routine which kept them from being garbage collected such that it ran > successfully. > > You should be using runtime.KeepAlive. That's what it's for. When > you put a finalizer on a Go pointer that points to a C pointer, and > the finalizer frees the C pointer, and you pass the C pointer to C > code, then you must be careful to use runtime.KeepAlive on the Go > pointer after every single call where it passes the C pointer into C. > > Ian > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/d6021daf-a1b4-4b54-a0e9-7fbc0f0160bd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
