nickeygit

As described here: https://github.com/go-gst/go-gst/issues/94#issuecomment-2240799955 We have **multiply** Glib signal handlers per every go-gst signal (signals.m map to closures). So, not all Glib closures are being freed. This can be a...

Looks like the go-glib patch has significantly helped with this issue - the leaking is really slow now. But still present. Testing against current/latest go-gst/go-glib. go version go1.22.5 linux/amd64 Mem...

> No the std is not leaking sync.Pool{}s But their allocated count is just increasing as the program running. > The pool doesn't get leaked, but the values from the...

> In combination with the LSP this regularily locks up my whole machine. "Minor usage" is only relevant for a single compilation. > > See also golang/go#50151 (comment) Hi Wilhelm,...

> PS: interface segregation has nothing to to with package sizes/compile times. If create proper interfaces which depend only on required set of code - then there will be no...

Hi @Scusemua ! Thanks for your patch! You saved me several hours of life! :)) And now my turn. PyGILState locking is needed for sure, but Go is insidious too...

Hi guys, I'm trying to fix this issue - and got a working fix/workaround. The test code in the initial comment - does work (including uncommented runtime.GC() - which makes...

Ok. And what about 2-nd part - defers? It's another issue - too early objects freeing by GC.

> It may be that the signal handler Ids are only unique per object, which could mean that the current implementation is broken in more ways than expected... You are...

Also, have created a native C equivalent of this test code, multithreaded. And it is runing just fine, not crashing. But still slightly mem-leaking.