Most likely your C code is somehow corrupting the Go heap. Try running your program with the environment variable GODEBUG set to cgocheck=2. Try running your program with the address sanitizer (-fsanitize=address).

@ianlancetaylor I tried the following command GODEBUG=cgocheck=2 ./ttt -fsanitize=address, but when it crashed, I only get the same messages as before. Did I type the correct command?

The GODEBUG setting is correct, though I guess it didn't help. The -fsanitize=address option is not. I was suggesting that you use that option when compiling your C code. This problem looks like memory corruption, which is almost certainly coming from the C code; you need to figure out what the C code is doing wrong.

@ianlancetaylor Actually, I have tested my C code by using valgrind. It told me that there is no memory leaks and everything is okay. I also used a loop(10000 times), to malloc and free the memory, but nothing crashed.
In the C code, printf("%d\n", *rgcmap); tells you the address allocated by malloc. And the error occurs in Go(line 78 fmt.Print("address", svc.maps)), which means the Go can not access to the maps of svc. Am I correct?

The stack trace shows that a value that Go thinks should hold a pointer actually holds the value 0x20, which is not a valid pointer value. That is why the Go runtime is crashing.

My first guess would be memory corruption. But it is also possible that you are using a Go pointer to hold a value returned from C, and for some reason C is returning the value 0x20. That could cause this problem.

@ianlancetaylor I have a basic question. How to analyse the runtime stack? For example, my Go code is fmt.Print("address", svc.maps), and the runtime stack is fmt.Print(0xc8202bfe78, 0x2, 0x2, 0x4d5d00, 0x0, 0x0). How to make the connections between them? As I am thinking why you said that C is returning the value 0x20.
Basically, I have printed the address of the value which allocated by malloc. This address is -603977536. which I think is correct( is not 0x20)
So, I think that we still do not find the problem.

The stack traceback maps to the arguments. A string is two words, a pointer, and a length, so in your example 0xc8202bfe78 is the string pointer and 0x2 is the string length. I don't know the type of svc.maps but the values you show suggest that it is four words long.

I never thought that malloc was returning 0x20. That would not make sense. I think that somewhere in your code a value that Go thinks holds a pointer is actually holding the value 0x20.

This has been opened for years and it's hard to investigate without a reproducer. As Ian said, it seems likely that the crash is caused by issues in cgo code; I'm closing this issue.