本文共 8900 字，大约阅读时间需要 29 分钟。
转载：
碰倒go 调用c 崩溃问题，本来以为是 cgo的问题。看了下原来是c编译的问题。参考文章如下：
简化示例
示例代码分别放在main.c和test.c中，main.c内容如下：
//main.c//公众号编程珠玑#include#include int main(void){ void *p = NULL; //打印p的地址 printf("%p\n",&p); //为p赋值 p = testFun(); printf("%p\n",p); //释放内存 free(p); p = NULL; return 0;}
test.c的内容如下：
//test.c#include#include void *testFun(){ //申请内存需要足够大，能方便达到本文的示例效果 void *p = (void*)malloc(1024*1024*10); if(NULL == p) { printf("malloc failed\n"); } printf("malloc success,p = %p\n",p); return p;}
上面两段代码再简单不过，testFun在函数中申请一段内存，并返回。而main函数通过调用testFun，将地址值返回给p，并打印p的地址值。
编译运行：
$ gcc -o main main.c test.c$ ./main0x7ffef59d4230malloc success,p = 0x7f193ec5f0100x3ec5f010Segmentation fault (core dumped)
从运行结果中，我们可以发现以下几个事实：
- 64位程序地址为8字节
- testFun内部申请到的内存地址值是占用8字节的值
- main函数中的p的地址值为4字节
- 返回值被截断了
也就是和我们预期的结果完全不一样。我们逐步分析，到底是为什么。
特别说明：
如果赋值那一行改成下面这样p = (void*)testFun();
运行结果中如下：
0x7ffd5a75dbe0malloc success,p = 0x7fc6fb5ac0100xfffffffffb5ac010Segmentation fault (core dumped)
其实看到8字节的前面4字节都是f，就可以判断这个地址是非法的了。为什么？（提示：程序地址空间分布）。
为什么coredump？
这个问题很明显，因为申请内存得到的地址值与释放内存的地址不是同一个，因此导致coredump（coredump的查看可参考《》中的gdb部分）。
为什么地址值被截断？
在解释这个之前，我们先看一个简单的示例程序：
//testReturn.c#includetest(){ printf("test function\n"); return 0;}int main(void){ test(); return 0;}
编译：
$ gcc -o test testReturn.ctestReturn.c:2:1: warning: return type defaults to ‘int’ [-Wimplicit-int] test() ^
我们在编译的时候出现了一个警告，提示test函数没有返回值，会默认返回值为int。
也就是说，如果函数实际有返回值，但是函数返回值类型却没有指明，编译器会将其默认为int。
实际上前面的示例程序在编译的时候就有警告：
main.c: In function ‘main’:main.c:11:9: warning: implicit declaration of function ‘testFun’ [-Wimplicit-function-declaration] p = testFun(); ^main.c:11:7: warning: assignment makes pointer from integer without a cast [-Wint-conversion] p = testFun(); ^
两个警告的意思分别为：
- testFun没有声明
- 尝试从整形转换成指针
第一个警告很容易理解，虽然定义了testFun函数，但是在main函数中并没有声明。因此对mian函数来说，它在编译阶段（关于编译阶段，可参考《》），“看不到”testFun，因此会默认为其返回值为int。而正因如此，就有了第二个警告，提示从整型转换成指针。
到此其实也就真相大白了。既然testFun的返回值被编译器默认为int，返回一个8字节的指针类型，而返回值却是int，自然就会被截断了。
如何解决
既然知道原因所在，那么如何解决呢？这里提供两种方式。
- extern声明
- 在头文件中声明，调用者包含该头文件
按照第一种方式，在main.c中增加一行声明：
extern void *testFun();
运行结果：
0x7fffee1bd7b0malloc success,p = 0x7fcafef2e0100x7fcafef2e010
第二种方式，增加test.h，内容为testFun的声明：
//test.h#include#include void *testFun();
main.c包含test.h头文件：
//main.c//公众号编程珠玑#include"test.h"int main(void){ void *p = NULL; //打印p的地址 printf("%p\n",&p); //为p赋值 p = testFun(); printf("%p\n",p); //释放内存 free(p); p = NULL; return 0;} test.c修改如下：
//test.c#include"test.h"void *testFun(){ void *p = (void*)malloc(1024*1024*10); if(NULL == p) { printf("malloc failed\n"); } printf("malloc success,p = %p\n",p); return p;} 以上两种方式都可解决前面的问题。
而32位程序为什么正常？相信你已经有了答案。
总结
由于对出现问题的程序代码不熟悉，加上其编译工程充斥着大量的警告而没有处理，以及涉及动态库，导致这个引起挂死问题的罪魁祸首没有提前暴露处出来。而问题的根本原因我们也清楚了，就是因为调用函数前没有声明。本文总结如下：
- 不要忽略任何一个警告，除非你非常清楚地知道自己在做什么
- 在头文件中声明函数，并提供给调用者
- 函数使用前进行声明
- 问题长期定位不出来时，休息一下
- 尽量编写通用性代码
- 非必要时不强转
- 使用void *指针格外小心
指针的字节数与 系统32位还是64位有关，但是 c int 的位数，和系统位数，和编译器，等有关。64位上的int gcc 是 4个字节的。
c 函数 需要声明。
go 调用 c
2.7.1 Go访问C内存
C语言空间的内存是稳定的，只要不是被人为提前释放，那么在Go语言空间可以放心大胆地使用。在Go语言访问C语言内存是最简单的情形，我们在之前的例子中已经见过多次。
因为Go语言实现的限制，我们无法在Go语言中创建大于2GB内存的切片（具体请参考makeslice实现代码）。不过借助cgo技术，我们可以在C语言环境创建大于2GB的内存，然后转为Go语言的切片使用：
package main /* #include <stdlib.h> void* makeslice(size_t memsize) { return malloc(memsize); } */ import "C" import "unsafe" func makeByteSlize(n int ) [] byte { p := C.makeslice(C.size_t(n)) return ((*[ 1 << 31 ] byte )(p))[ 0 :n:n] } func freeByteSlice(p [] byte ) { C.free(unsafe.Pointer(&p[ 0 ])) } func main() { s := makeByteSlize( 1 << 32 + 1 ) s[ len [s] -1 ] = 1234 print (s[ len [s] -1 ]) freeByteSlice(p) }
例子中我们通过makeByteSlize来创建大于4G内存大小的切片，从而绕过了Go语言实现的限制（需要代码验证）。而freeByteSlice辅助函数则用于释放从C语言函数创建的切片。
因为C语言内存空间是稳定的，基于C语言内存构造的切片也是绝对稳定的，不会因为Go语言栈的变化而被移动。
2.7.2 C临时访问传入的Go内存
cgo之所以存在的一大因素是为了方便在Go语言中接纳吸收过去几十年来使用C/C++语言软件构建的大量的软件资源。C/C++很多库都是需要通过指针直接处理传入的内存数据的，因此cgo中也有很多需要将Go内存传入C语言函数的应用场景。
假设一个极端场景：我们将一块位于某goroutinue的栈上的Go语言内存传入了C语言函数后，在此C语言函数执行期间，此goroutinue的栈因为空间不足的原因发生了扩展，也就是导致了原来的Go语言内存被移动到了新的位置。但是此时此刻C语言函数并不知道该Go语言内存已经移动了位置，仍然用之前的地址来操作该内存——这将将导致内存越界。以上是一个推论（真实情况有些差异），也就是说C访问传入的Go内存可能是不安全的！
当然有RPC远程过程调用的经验的用户可能会考虑通过完全传值的方式处理：借助C语言内存稳定的特性，在C语言空间先开辟同样大小的内存，然后将Go的内存填充到C的内存空间；返回的内存也是如此处理。下面的例子是这种思路的具体实现：
package main /* void printString(const char* s) { printf("%s", s); } */ import "C" func printString(s string ) { cs := C.CString(s) defer C.free(unsafe.Pointer(cs)) C.printString(cs) } func main() { s := "hello" printString(s) }
在需要将Go的字符串传入C语言时，先通过 C.CString 将Go语言字符串对应的内存数据复制到新创建的C语言内存空间上。上面例子的处理思路虽然是安全的，但是效率极其低下（因为要多次分配内存并逐个复制元素），同时也极其繁琐。
为了简化并高效处理此种向C语言传入Go语言内存的问题，cgo针对该场景定义了专门的规则：在CGO调用的C语言函数返回前，cgo保证传入的Go语言内存在此期间不会发生移动，C语言函数可以大胆地使用Go语言的内存！
根据新的规则我们可以直接传入Go字符串的内存：
package main /* #include<stdio.h> void printString(const char* s, int n) { int i; for(i = 0; i < n; i++) { putchar(s[i]); } putchar('\n'); } */ import "C" func printString(s string ) { p := (*reflect.StringHeader)(unsafe.Pointer(&s)) C.printString((*C.char)(unsafe.Pointer(p.Data)), C. int ( len (s))) } func main() { s := "hello" printString(s) }
现在的处理方式更加直接，且避免了分配额外的内存。完美的解决方案！
任何完美的技术都有被滥用的时候，CGO的这种看似完美的规则也是存在隐患的。我们假设调用的C语言函数需要长时间运行，那么将会导致被他引用的Go语言内存在C语言返回前不能被移动，从而可能间接地导致这个Go内存栈对应的goroutine不能动态伸缩栈内存，也就是可能导致这个goroutine被阻塞。因此，在需要长时间运行的C语言函数（特别是在纯CPU运算之外，还可能因为需要等待其它的资源而需要不确定时间才能完成的函数），需要谨慎处理传入的Go语言内存。
不过需要小心的是在取得Go内存后需要马上传入C语言函数，不能保存到临时变量后再间接传入C语言函数。因为CGO只能保证在C函数调用之后被传入的Go语言内存不会发生移动，它并不能保证在传入C函数之前内存不发生变化。
以下代码是错误的：
// 错误的代码 tmp := uintptr (unsafe.Pointer(&x)) pb := (* int16 )(unsafe.Pointer(tmp)) *pb = 42
因为tmp并不是指针类型，在它获取到Go对象地址之后x对象可能会被移动，但是因为不是指针类型，所以不会被Go语言运行时更新成新内存的地址。在非指针类型的tmp保持Go对象的地址，和在C语言环境保持Go对象的地址的效果是一样的：如果原始的Go对象内存发生了移动，Go语言运行时并不会同步更新它们。
2.7.3 C长期持有Go指针对象
作为一个Go程序员在使用CGO时潜意识会认为总是Go调用C函数。其实CGO中，C语言函数也可以回调Go语言实现的函数。特别是我们可以用Go语言写一个动态库，导出C语言规范的接口给其它用户调用。当C语言函数调用Go语言函数的时候，C语言函数就成了程序的调用方，Go语言函数返回的Go对象内存的生命周期也就自然超出了Go语言运行时的管理。简言之，我们不能在C语言函数中直接使用Go语言对象的内存。
虽然Go语言禁止在C语言函数中长期持有Go指针对象，但是这种需求是切实存在的。如果需要在C语言中访问Go语言内存对象，我们可以将Go语言内存对象在Go语言空间映射为一个int类型的id，然后通过此id来间接访问和控制Go语言对象。
以下代码用于将Go对象映射为整数类型的ObjectId，用完之后需要手工调用free方法释放该对象ID：
package main import "sync" type ObjectId int32 var refs struct { sync.Mutex objs map [ObjectId] interface {} next ObjectId } func init() { refs.Lock() defer refs.Unlock() refs.objs = make ( map [ObjectId] interface {}) refs.next = 1000 } func NewObjectId(obj interface {}) ObjectId { refs.Lock() defer refs.Unlock() id := refs.next refs.next++ refs.objs[id] = obj return id } func (id ObjectId) IsNil() bool { return id == 0 } func (id ObjectId) Get() interface {} { refs.Lock() defer refs.Unlock() return refs.objs[id] } func (id *ObjectId) Free() interface {} { refs.Lock() defer refs.Unlock() obj := refs.objs[*id] delete (refs.objs, *id) *id = 0 return obj }
我们通过一个map来管理Go语言对象和id对象的映射关系。其中NewObjectId用于创建一个和对象绑定的id，而id对象的方法可用于解码出原始的Go对象，也可以用于结束id和原始Go对象的绑定。
下面一组函数以C接口规范导出，可以被C语言函数调用：
package main /* extern char* NewGoString(char* ); extern void FreeGoString(char* ); extern void PrintGoString(char* ); static void printString(const char* s) { char* gs = NewGoString(s); PrintGoString(gs); FreeGoString(gs); } */ import "C" //export NewGoString func NewGoString(s *C.char) *C.char { gs := C.GoString(s) id := NewObjectId(gs) return (*C.char)(unsafe.Pointer( uintptr (id))) } //export FreeGoString func FreeGoString(p *C.char) { id := ObjectId( uintptr (unsafe.Pointer(p))) id.Free() } //export PrintGoString func PrintGoString(s *C.char) { id := ObjectId( uintptr (unsafe.Pointer(p))) gs := id.Get().( string ) print (gs) } func main() { C.printString( "hello" ) }
在printString函数中，我们通过NewGoString创建一个对应的Go字符串对象，返回的其实是一个id，不能直接使用。我们借助PrintGoString函数将id解析为Go语言字符串后打印。该字符串在C语言函数中完全跨越了Go语言的内存管理，在PrintGoString调用前即使发生了栈伸缩导致的Go字符串地址发生变化也依然可以正常工作，因为该字符串对应的id是稳定的，在Go语言空间通过id解码得到的字符串也就是有效的。
2.7.4 导出C函数不能返回Go内存
在Go语言中，Go是从一个固定的虚拟地址空间分配内存。而C语言分配的内存则不能使用Go语言保留的虚拟内存空间。在CGO环境，Go语言运行时默认会检查导出返回的内存是否是由Go语言分配的，如果是则会抛出运行时异常。
下面是CGO运行时异常的例子：
/* extern int* getGoPtr(); static void Main() { int* p = getGoPtr(); *p = 42; } */ import "C" func main() { C.Main() } //export getGoPtr func getGoPtr() *C. int { return new (C. int ) }
其中getGoPtr返回的虽然是C语言类型的指针，但是内存本身是从Go语言的new函数分配，也就是由Go语言运行时统一管理的内存。然后我们在C语言的Main函数中调用了getGoPtr函数，此时默认将发送运行时异常：
$ go run main.go panic: runtime error: cgo result has Go pointer goroutine 1 [running]: main._cgoexpwrap_cfb3840e3af2_getGoPtr.func1(0xc420051dc0) command-line-arguments/_obj/_cgo_gotypes.go:60 +0x3a main._cgoexpwrap_cfb3840e3af2_getGoPtr(0xc420016078) command-line-arguments/_obj/_cgo_gotypes.go:62 +0x67 main._Cfunc_Main() command-line-arguments/_obj/_cgo_gotypes.go:43 +0x41 main.main() /Users/chai/go/src/github.com/chai2010/advanced-go-programming-book/examples/ch2-xx/return-go-ptr/main.go:17 +0x20 exit status 2异常说明cgo函数返回的结果中含有Go语言分配的指针。指针的检查操作发生在C语言版的getGoPtr函数中，它是由cgo生成的桥接C语言和Go语言的函数。
c 指针的打印：
%x %p
参考：