cgo 崩溃 64位地址截断引发的挂死问题

最新推荐文章于 2023-06-29 10:35:20 发布

shanandqiu

最新推荐文章于 2023-06-29 10:35:20 发布

阅读量942

点赞数

原文链接：https://zhuanlan.zhihu.com/p/70965375

版权

转载： https://zhuanlan.zhihu.com/p/70965375

碰倒go 调用c 崩溃问题，本来以为是 cgo的问题。看了下原来是c编译的问题。参考文章如下：

简化示例

示例代码分别放在main.c和test.c中，main.c内容如下：

//main.c
//公众号编程珠玑
#include<stdio.h>
#include<stdlib.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<stdio.h>
#include<stdlib.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;
}

上面两段代码再简单不过，testFun在函数中申请一段内存，并返回。而main函数通过调用testFun，将地址值返回给p，并打印p的地址值。

编译运行：

$ gcc -o main main.c test.c
$ ./main
0x7ffef59d4230
malloc success,p = 0x7f193ec5f010
0x3ec5f010
Segmentation fault (core dumped)

从运行结果中，我们可以发现以下几个事实：

64位程序地址为8字节
testFun内部申请到的内存地址值是占用8字节的值
main函数中的p的地址值为4字节
返回值被截断了

也就是和我们预期的结果完全不一样。我们逐步分析，到底是为什么。

特别说明：
如果赋值那一行改成下面这样

p = (void*)testFun();

运行结果中如下：

0x7ffd5a75dbe0
malloc success,p = 0x7fc6fb5ac010
0xfffffffffb5ac010
Segmentation fault (core dumped)

其实看到8字节的前面4字节都是f，就可以判断这个地址是非法的了。为什么？（提示：程序地址空间分布）。

为什么coredump？

这个问题很明显，因为申请内存得到的地址值与释放内存的地址不是同一个，因此导致coredump（coredump的查看可参考《linux常用命令-开发调试篇》中的gdb部分）。

为什么地址值被截断？

在解释这个之前，我们先看一个简单的示例程序：

//testReturn.c
#include<stdio.h>
test()
{
    printf("test function\n");
    return 0;
}
int main(void)
{
    test();
    return 0;
}

编译：

$ gcc -o test testReturn.c
testReturn.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函数来说，它在编译阶段（关于编译阶段，可参考《hello程序是如何变成可执行文件的》），“看不到”testFun，因此会默认为其返回值为int。而正因如此，就有了第二个警告，提示从整型转换成指针。

到此其实也就真相大白了。既然testFun的返回值被编译器默认为int，返回一个8字节的指针类型，而返回值却是int，自然就会被截断了。

如何解决

既然知道原因所在，那么如何解决呢？这里提供两种方式。

extern声明
在头文件中声明，调用者包含该头文件

按照第一种方式，在main.c中增加一行声明：

extern void *testFun();

运行结果：

0x7fffee1bd7b0
malloc success,p = 0x7fcafef2e010
0x7fcafef2e010

第二种方式，增加test.h，内容为testFun的声明：

//test.h
#include<stdio.h>
#include<stdlib.h>
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

参考：

http://reader.epubee.com/books/mobile/85/8532811f0c94d155b601ae8325455409/text00003.html

shanandqiu

关注

0
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
cgo 崩溃 64位地址截断引发的挂死问题

转载：https://zhuanlan.zhihu.com/p/70965375碰倒go 调用c 崩溃问题，本来以为是 cgo的问题。看了下原来是c编译的问题。参考文章如下：简化示例示例代码分别放在main.c和test.c中，main.c内容如下：//main.c//公众号编程珠玑#include<stdio.h>#include<stdlib.h>int main(void){ void *p = NULL; //打印...
复制链接

扫一扫