CODEWITHSUNDEEP
gomemory-leaks
Wyatt
Wyatt

Reputation: 141

memory leaks in golang

Here is the code. In the golang main function, which in main.go

func main() {
    rgc.GetRgcService()
}

where the rgc is in another golang file, named mrgc.go. The code inside is

package rgc
func GetRgcService() (svc *RgcService, err error) {}

The function GetRgcService is a empty function.

However, when I used valgrind to test the memory, I got the following output

 ==58156== HEAP SUMMARY:
 ==58156==     in use at exit: 1,152 bytes in 4 blocks
 ==58156==   total heap usage: 9 allocs, 5 frees, 1,304 bytes allocated
 ==58156== 288 bytes in 1 blocks are possibly lost in loss record 4 of 4
 ==58156==    at 0x4A27F63: calloc (vg_replace_malloc.c:593)
 ==58156==    by 0x4010DE1: allocate_dtv (in /home/opt/gcc-4.8.2.bpkg-r2/gcc-4.8.2.bpkg-r2/lib64/ld-2.18.so)
==58156==    by 0x40114ED: _dl_allocate_tls (in /home/opt/gcc-4.8.2.bpkg-r2/gcc-4.8.2.bpkg-r2/lib64/ld-2.18.so)
==58156==    by 0x4B36DE2: pthread_create@@GLIBC_2.2.5 (in /home/opt/gcc-4.8.2.bpkg-r2/gcc-4.8.2.bpkg-r2/lib64/libpthread-2.18.so)
==58156==    by 0x4B2937: _cgo_sys_thread_start (gcc_linux_amd64.c:75)
==58156==    by 0x45506C: runtime.asmcgocall (/home/map/.jumbo/lib/go/src/runtime/asm_amd64.s:612)
==58156==    by 0x50619F: ??? (in /home/users/zhanghuaizhi/ttt.38)
==58156==    by 0xC7FFFFFFFF: ???
==58156==    by 0xC820067FFF: ???
==58156==    by 0x42D69B: runtime.allocm (/home/map/.jumbo/lib/go/src/runtime/proc.go:1260)
==58156==    by 0x42DD3A: runtime.newm (/home/map/.jumbo/lib/go/src/runtime/proc.go:1510)
==58156==    by 0x42E071: runtime.startm (/home/map/.jumbo/lib/go/src/runtime/proc.go:1583)
==58156== 
==58156== LEAK SUMMARY:
==58156==    definitely lost: 0 bytes in 0 blocks
==58156==    indirectly lost: 0 bytes in 0 blocks
==58156==      possibly lost: 1,152 bytes in 4 blocks
==58156==    still reachable: 0 bytes in 0 blocks
==58156==         suppressed: 0 bytes in 0 blocks

How can I free these memory? Since I need to used this function to do a lot of process. It causes lots of memory leaks, which can not be freed

Upvotes: 2

Views: 12478

Answers (2)

bobpaul
bobpaul

Reputation: 390

You can manually run garbage collection: https://golang.org/pkg/runtime/#GC

I think that would free up the memory, but as others have said, that memory will get freed eventually when the runtime's scheduled garbage collector runs.

Upvotes: 1

Art
Art

Reputation: 20392

Nothing was leaked. The memory is still reachable and it's quite common to not free things on exit, it just takes unnecessary time and the OS will deal with it anyway.

This is memory allocated to thread local storage to a thread that's still running, so it would be incorrect to free it. A better question would be "how do I stop this thread?", to which an answer is: you don't, the Go runtime deals with it. It is quite common to not stop threads at exit, it just takes unnecessary time and the OS will deal with it anyway.

It has nothing to do with your code and your function call, it's something that Go runtime allocates for itself.

Go is a garbage collected language and using valgrind on it will not tell you much. It will neither detect real memory leaks nor will it understand which memory is still in use.

Upvotes: 20

Related Questions