Sorry for the late reply. The problem was solved, thanks to everyone for the help.
Just to give a little more context. The lib that I'm using is MuPDF and I thought that I had a memory leak but in the end, it was just glibc not releasing the memory fast enough to the OS. I solved the problem by changing the allocator at MuPDF to jemalloc. At my first analysis, I did not know where was the problem because the code looked correct, as it was, but I started to think that maybe I was leaking the memory in C from the Go code calling things like C.CString. Then I thought how can I allocate in C from Go utility functions like C.CString using an allocator that has leak detection called memento that the MuPDF team built? Well, I still don't know. I did it once using unsafe, but not by using the actual C.CString call. And regards LD_PRELOAD I did not found a way of making everything work together, I don't have much experience with C. Em sábado, 12 de junho de 2021 às 10:40:22 UTC+1, Tamás Gulácsi escreveu: > You can use the LD_PRELOAD env var ( > https://www.ibm.com/docs/en/spectrum-symphony/7.2.1?topic=optimization-optimizing-memory-consumption-tcmalloc-jemalloc) > > to use > jemalloc or tcmalloc, and debug with them. > > [email protected] a következőt írta (2021. június 10., csütörtök, > 21:19:15 UTC+2): > >> I'm using cgo and struggling to find a memory leak which can be easily >> detected if I can replace the cgo memory allocator to the one the C library >> I'm using have because they did a leak detector implementation there. >> >> It's possible? >> >> >> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/b0c67495-e456-462c-817d-9f5500714b0fn%40googlegroups.com.
