golang调用巨杉c客户端，总是会运行一段时间后core

使用更先进的浏览器访问效果更佳。

golang调用巨杉c客户端，总是会运行一段时间后core

旭asa

如题，通过golang调用巨杉c库，可以正常运行，但运行一段时间后就会core，gdb信息如下，调用sdbConnect和sdbConnect1都会抛出相同错误，很诡异。有时运行几分钟会core，有时运行俩三天才会core，我们每次会写入大量数据，可以认为1小时会有几十万次upsert操作，会并发进行操作。线上是云主机环境，巨杉版本是1.12.4，尝试用1.12.5 c库运行报相同错误，下面的gdb是通过1.12.5版本的c库运行的

这是通过sdbConnect建立连接时

#0 runtime.raise () at /home/lizhengxu/tmp/go/src/runtime/sys_linux_amd64.s:110

#1 0x0000000000440458 in runtime.dieFromSignal (sig=6) at /home/lizhengxu/tmp/go/src/runtime/signal1_unix.go:192

#2 0x000000000044057f in runtime.crash () at /home/lizhengxu/tmp/go/src/runtime/signal1_unix.go:247

#3 0x000000000042e38e in runtime.dopanic_m (gp=0xc821a5ac00, pc=4382096, sp=140175644784776) at /home/lizhengxu/tmp/go/src/runtime/panic.go:659

#4 0x0000000000453572 in runtime.dopanic.func1 () at /home/lizhengxu/tmp/go/src/runtime/panic.go:534

#5 0x000000000045c7eb in runtime.systemstack () at /home/lizhengxu/tmp/go/src/runtime/asm_amd64.s:307

#6 0x000000000042dcf1 in runtime.dopanic (unused=0) at /home/lizhengxu/tmp/go/src/runtime/panic.go:535

#7 0x000000000042dd90 in runtime.throw (s=...) at /home/lizhengxu/tmp/go/src/runtime/panic.go:547

#8 0x000000000044235a in runtime.sigpanic () at /home/lizhengxu/tmp/go/src/runtime/sigpanic_unix.go:12

#9 0x00007f80a479c728 in clientConnect (pHostName=0x3 , pServiceName=0xb376c0 "\n", useSSL=0, sock=0x7f7fb8007708) at SequoiaDB/engine/client/network.c:95

#10 0x00007f80a478af73 in _sdbConnect (pHostName=0x7f7d2f837b40 "10.0.0.0", pServiceName=0x7f7d2f837b00 "11810", pUsrName=0x7f7d2f837ac0 "", pPasswd=0x7f7d2f837a80 "", useSSL=0,

handle=0x7f7fb80076c0) at SequoiaDB/engine/client/client.c:1291

#11 0x00000000009652c3 in iSdbConnect (host=, port=, usrName=, passwd=0x7f7fb80076a0 "", connection=)

at /home/lizhengxu/go/zeus/zeus_stats_info/src/zeus_stats_info/processor/util.go:27

#12 0x00000000009653a9 in _cgo_980604af2394_C2func_iSdbConnect (v=0xc82103f808) at /home/lizhengxu/go/zeus/zeus_stats_info/src/zeus_stats_info/processor/util.go:69

#13 0x000000000045e180 in runtime.asmcgocall () at /home/lizhengxu/tmp/go/src/runtime/asm_amd64.s:582

#14 0x0000000000000008 in ?? ()

#15 0x000000c82103f778 in ?? ()

#16 0x000000000040448a in runtime.cgocall (fn=0xc82001b500, arg=0x0, ~r2=564505600) at /home/lizhengxu/tmp/go/src/runtime/cgocall.go:110

#17 0x00000000004321f0 in runtime.startTheWorldWithSema () at /home/lizhengxu/tmp/go/src/runtime/proc.go:986

#18 0x000000c82001b500 in ?? ()

#19 0x0000000000000000 in ?? ()

这是通过sdbConnect1建立连接时

#0 runtime.raise () at /home/lizhengxu/tmp/go/src/runtime/sys_linux_amd64.s:110

#1 0x00000000004404a8 in runtime.dieFromSignal (sig=6) at /home/lizhengxu/tmp/go/src/runtime/signal1_unix.go:192

#2 0x00000000004405cf in runtime.crash () at /home/lizhengxu/tmp/go/src/runtime/signal1_unix.go:247

#3 0x000000000042e3de in runtime.dopanic_m (gp=0xc8204ba180, pc=4382176, sp=140707190782328) at /home/lizhengxu/tmp/go/src/runtime/panic.go:659

#4 0x00000000004535c2 in runtime.dopanic.func1 () at /home/lizhengxu/tmp/go/src/runtime/panic.go:534

#5 0x000000000045c83b in runtime.systemstack () at /home/lizhengxu/tmp/go/src/runtime/asm_amd64.s:307

#6 0x000000000042dd41 in runtime.dopanic (unused=0) at /home/lizhengxu/tmp/go/src/runtime/panic.go:535

#7 0x000000000042dde0 in runtime.throw (s=...) at /home/lizhengxu/tmp/go/src/runtime/panic.go:547

#8 0x00000000004423aa in runtime.sigpanic () at /home/lizhengxu/tmp/go/src/runtime/sigpanic_unix.go:12

#9 0x00007ff90e069728 in clientConnect (pHostName=0x3 , pServiceName=0xb378d8 "\n", useSSL=0, sock=0x7ff8dc003f08) at SequoiaDB/engine/client/network.c:95

#10 0x00007ff90e057f73 in _sdbConnect (pHostName=0x7ff8dc000ae0 "10.0.0.0", pServiceName=0x7ff8dc000aed "11810", pUsrName=0x7ff8dc000a60 "", pPasswd=0x7ff8dc000a80 "", useSSL=0,

handle=0x7ff8dc003620) at SequoiaDB/engine/client/client.c:1291

#11 0x00007ff90e0582be in _sdbConnect1 (pConnAddrs=0xc820afdfc0, arrSize=3, pUsrName=0x7ff8dc000a60 "", pPasswd=0x7ff8dc000a80 "", useSSL=0, handle=0x7ff8dc003620)

at SequoiaDB/engine/client/client.c:1421

#12 0x00000000009653a8 in _cgo_7399d60e875e_C2func_sdbConnect1 (v=0xc820a477d0) at /home/lizhengxu/go/zeus/zeus_stats_info/src/zeus_stats_info/processor/util.go:70

#13 0x000000000045e1d0 in runtime.asmcgocall () at /home/lizhengxu/tmp/go/src/runtime/asm_amd64.s:582

#14 0x0000000000000008 in ?? ()

#15 0x000000c820a47738 in ?? ()

#16 0x00000000004044da in runtime.cgocall (fn=0xc820023500, arg=0x0, ~r2=541827456) at /home/lizhengxu/tmp/go/src/runtime/cgocall.go:110

#17 0x0000000000432240 in runtime.startTheWorldWithSema () at /home/lizhengxu/tmp/go/src/runtime/proc.go:986

#18 0x000000c820023500 in ?? ()

#19 0x0000000000000000 in ?? ()

这里_sdbConnect 时传入的host地址，因为是线上环境，改写成了"10.0.0.0"，其余信息是gdb完整输出，源地址格式是"xx.xx.xx.xxx"

可以看到_sdbConnect (pHostName=0x7ff8dc000ae0 "10.0.0.0", pServiceName=0x7ff8dc000aed "11810", 的地址都是正确的，但到了clientConnect (pHostName=0x3 , pServiceName=0xb378d8 "\n", 这里就错了，纠结俩周一直没能找出原因，不知哪位大牛有碰到过吗？

davidli

#9 0x00007ff90e069728 in clientConnect (pHostName=0x3 , pServiceName=0xb378d8 "\n", useSSL=0, sock=0x7ff8dc003f08) at SequoiaDB/engine/client/network.c:95

pHostName地址怎么变了？

旭asa

是的，现在就是搞不懂这个原因，传入这个地址时在go是调用了c的代码，通过c创建变量并重新分配空间，然后复制字符串，传入sdbConnect，这个c的变量是没有再被其他地方使用的。

而且理论上go的gc也不会干涉c分配的内存才对。诡异的是每次出错时pHost都是0x3，pService都是"\n"

davidli

cgo里面怎么封装的sdbConnect1()，go字符串怎么转换成c字符串的？

davidli

把封装接口的代码贴出来看看

旭asa

最外层就是调用 iSdbConnect，从gdb信息来看，iSdbConnect是正确传入地址和端口到 sdbConnect才对

而且这里的都是重新分配的内存，局部变量

旭asa

davidli

golang的切片应该不能通过指针直接转成clang的字符串数组吧，这里好像有问题！

davidli

I'm wrapping a C library using cgo and need to call a function that

has a char** (i.e., char*[]) parameter. The approach I've taken so

far is:

C helper functions:

static char**makeCharArray(int size) {

return calloc(sizeof(char*), size);

}

static void setArrayString(char **a, char *s, int n) {

a[n] = s;

}

static void freeCharArray(char **a, int size) {

int i;

for (i = 0; i < size; i++)

free(a[i]);

free(a);

}

Called like so:

cargs := C.makeCharArray(C.int(len(sargs)))

defer C.freeCharArray(cargs, C.int(len(sargs)))

for i, s := range sargs {

C.setArrayString(cargs, C.CString(s), C.int(i))

}

It works but it feels a bit fiddly. Is there a better way?

旭asa

也怀疑过这个问题，所以也尝试过这种字符串方式，也还是报相同错误

davidli

不是这里，上面go转cgo的地方，你把在golang里make出的slice直接用指针转成clang的地址，这是不对的

旭asa

那个测试结果是可以运行的

而且那是在调用sdcConnect1时使用的方法

调用sdbConnect时并没有把slice转换成c的地址，因为sdbConnect只需要地址和端口的字符串嘛

问题是调用sdbConnect时也会报相同错误具体代码如下

但这种方式也还是会出现一样的core

davidli

切片的内存受golang运行时管理，而unsafe.Pointer是不安全的，可能会出现GC回收了切片内存但是unsafe.Pointer还在使用的情况，有问题，出现问题的时机要看GC何时回收了切片对象。

davidli

golang用的哪个版本？

旭asa

我试了俩种方式调用巨杉c库，一个是sdbConnect1，这里会用切片一个是sdbConnect，这里没有切片，只有String转char，

所以切片跟core应该是没有关系的

旭asa

1.3.3和1.6.3都试过，都一样的core

davidli

看不到整体的代码，没法定位问题。

从coredump的堆栈看像是内存被踩了，不好定位，试试用valgrind跑跑看。

旭asa

试过了，但是信息显示不准

今天试了下在gdb里跑服务，信息跟之前不同，如下

之前是显示地址错误，但这里显示到clientConnect的地址和值都是正确的，不确定是不是go的core dump再gdb导致之前的并不是准确的

从这里看感觉是 gethostbyname 返回结果直接调用 h_addr_list[0] 导致的内存错误

用的c client是 1.12.5

旭asa

因为新发现的信息跟之前不一致，新发了个贴

应该是c驱动的bug，算是解决了

感谢这俩天一起探讨这个问题~

http://bbs.sequoiadb.com/cn/foru ... 1240&page=1#pid2924