Python libsvm 核心转储
我有一段Python代码，在我的开发环境（Ubuntu 12.04）上运行得很好，但在我的生产环境（一个运行CentOS的Linode服务器）上却崩溃了。
*** glibc detected *** python2.7: double free or corruption (out): 0x090cba60 ***
======= Backtrace: =========
/lib/i686/nosegneg/libc.so.6(+0x717b1)[0xb763d7b1]
/lib/i686/nosegneg/libc.so.6(+0x73f01)[0xb763ff01]
/home/michael/libsvm-3.16/python/../libsvm.so.2(svm_free_model_content+0xe2)[0xb6e0c6b2]
/home/michael/libsvm-3.16/python/../libsvm.so.2(svm_free_and_destroy_model+0x2c)[0xb6e0c70c]
/home/michael/lib/python2.7/lib-dynload/_ctypes.so(ffi_call_SYSV+0x17)[0xb71e375f]
/home/michael/lib/python2.7/lib-dynload/_ctypes.so(ffi_call+0x5b)[0xb71e35ab]
/home/michael/lib/python2.7/lib-dynload/_ctypes.so(_ctypes_callproc+0x32d)[0xb71d82ad]
/home/michael/lib/python2.7/lib-dynload/_ctypes.so(+0x703e)[0xb71d003e]
python2.7(PyObject_Call+0x4a)[0x805d90a]
python2.7(PyEval_EvalFrameEx+0x3c0a)[0x80e04ba]
python2.7(PyEval_EvalCodeEx+0x7bb)[0x80e2c1b]
python2.7[0x813ee2a]
python2.7(PyObject_Call+0x4a)[0x805d90a]
python2.7[0x80657f1]
python2.7(PyObject_Call+0x4a)[0x805d90a]
python2.7(PyEval_CallObjectWithKeywords+0x42)[0x80db852]
python2.7[0x80af616]
python2.7[0x80a928e]
python2.7[0x808e024]
python2.7[0x8067c5b]
python2.7[0x808c079]
python2.7(PyDict_SetItem+0x87)[0x808cfa7]
python2.7(_PyModule_Clear+0x123)[0x8090693]
python2.7(PyImport_Cleanup+0x175)[0x80f2ca5]
python2.7(Py_Finalize+0x10c)[0x80ffacc]
python2.7(Py_Main+0x53d)[0x8058c1d]
python2.7(main+0x1b)[0x805839b]
/lib/i686/nosegneg/libc.so.6(__libc_start_main+0xe6)[0xb75e2ce6]
python2.7[0x80582e1]
======= Memory map: ========
08048000-0817d000 r-xp 00000000 ca:00 430104 /home/michael/bin/python2.7
0817d000-081ab000 rw-p 00134000 ca:00 430104 /home/michael/bin/python2.7
081ab000-081b4000 rw-p 00000000 00:00 0
...
这种情况经常发生，但不是每次都会。更有趣的是，如果我删除libsvm子目录下的*.pyc文件，代码似乎就能正常运行，但一旦这些*.pyc文件在第一次运行后重新生成，崩溃的情况又会出现。
另外，如果我尝试将标准错误输出重定向到一个文件，它就不会崩溃。
一些可能相关的信息：
- 这个问题只在我安装了Python 2.7后开始出现，之前用Python 2.6时没有这个问题。
- Python 2.7是我从源代码安装到我的主目录里的，因为CentOS没有提供python2.7的安装包。
我应该如何解决这个问题？问题最可能出在哪里？是在libsvm的源代码里，还是在Python的封装里？我很确定问题不在我的Python源代码里，因为我不应该能让解释器崩溃。
编辑
我在生产环境中重新训练了模型，问题似乎解决了。为了参考，这里是我在开发环境和生产环境中使用的两个模型的差异。
第一个模型的头部差异：
4,7c4,7
< total_sv 8858
< rho -0.500251 -0.215012 2.99972 -0.00159202 0.000223509 1.00003
< label 3 2 1 0
< nr_sv 549 6095 587 1627
---
> total_sv 8782
> rho -2.99981 0.000329574 -1.00015 -0.335094 -0.999424 -0.66958
> label 0 3 2 1
> nr_sv 1586 535 6083 578
-bash-4.1$ diff model.svm model2.svm | head -n 20
4,7c4,7
< total_sv 8858
< rho -0.500251 -0.215012 2.99972 -0.00159202 0.000223509 1.00003
< label 3 2 1 0
< nr_sv 549 6095 587 1627
第二个模型的头部差异：
4,7c4,7
< total_sv 116
< rho 2.30068 -0.145028 0.169511 -1.09344 0.723723 -0.865381
< label 3 0 2 1
< nr_sv 18 32 34 32
---
> total_sv 132
> rho 0.72381 -2.00473 -0.220492 -0.962109 0.998243 -0.14499
> label 0 1 3 2
> nr_sv 43 35 18 36
1 个回答
3
这个错误的原因是一个没有初始化的指针出现在svm_load_model函数里，还有一个没有检查的free调用。这里有一个修复的代码：
misha@misha-diginnos:~$ diff libsvm-3.16/svm.cpp.original libsvm-3.16/svm.cpp -p
*** libsvm-3.16/svm.cpp.original 2013-03-17 17:34:00.235661297 +0900
--- libsvm-3.16/svm.cpp 2013-03-17 17:39:29.677294903 +0900
*************** svm_model *svm_load_model(const char *mo
*** 2747,2752 ****
--- 2747,2753 ----
model->probB = NULL;
model->label = NULL;
model->nSV = NULL;
+ model->sv_indices = NULL;
char cmd[81];
while(1)
*************** void svm_free_model_content(svm_model* m
*** 2973,2980 ****
free(model_ptr->probB);
model_ptr->probB= NULL;
! free(model_ptr->sv_indices);
! model_ptr->sv_indices = NULL;
free(model_ptr->nSV);
model_ptr->nSV = NULL;
--- 2974,2984 ----
free(model_ptr->probB);
model_ptr->probB= NULL;
! if (model_ptr->sv_indices)
! {
! free(model_ptr->sv_indices);
! model_ptr->sv_indices = NULL;
! }
free(model_ptr->nSV);
model_ptr->nSV = NULL;
我已经通知了作者。他们知道这个问题，并会在下一个版本中解决它。