On Fri, May 24, 2019 at 3:05 AM <zodn...@gmail.com> wrote:
>
> 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.
I took a look at the code. Some things that stand out immediately:
- Dozen of comments in Go code using "Golang" as the name of the language.
- Yoda with happy is
func (buft *BufferT) Free() {
if nil == buft {
return
}
if true == buft.ownsBuff {
buft.cbuft.Free()
}
buft.cbuft = nil
}
(https://gitlab.com/YottaDB/Lang/YDBGo/blob/4a8c7ab467677c664e1a52ac2b87a9a537cbb605/buffer_t.go#L138)
- It seems that in more than one place the code violates the rules
about Go pointers crossing the CGo barrier, for example at
https://gitlab.com/YottaDB/Lang/YDBGo/blob/4a8c7ab467677c664e1a52ac2b87a9a537cbb605/buffer_t.go#L39
- Exported API that has unsafe.Pointer typed parameters:
https://gitlab.com/YottaDB/Lang/YDBGo/blob/4a8c7ab467677c664e1a52ac2b87a9a537cbb605/buffer_t.go#L39
while not even mentioning what's safe to pass as the unsafe pointer
argument. Must it be only pointer to C allocated memory or can it be a
pointer to anything managed by the Go runtime?
I looked at the code only for a few minutes, but the impression I got
is that this is not at all about "Aggressive Golang Garbage Collection
Issues When Using cgo". I think it instead about not
following/ignoring the documented rules for Go/CGo interaction as well
as not following/ignoring the documented rules about safe/supported
uses of unsafe.Pointers.
--
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/CAA40n-WgHO-249w%3Df5RsUbaggv-ehT56C1Q%3DPf6Ck3z%3D1uX%2Byg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
