[团队项目]expat不兼容BUG

本周五软工团队项目的第一次前后端全部对接时,出了一个蛋疼的错误。

最初起因是小丽叔出于安全的考虑,使用守护进程来跑Web服务器。守护进程(Daemon)是运行在后台的一种特殊进程,如果服务器用root权限来跑的话会有安全隐患,但是daemon本身无法更改一些没有放开权限的文件,即使网站被黑也不会有数据隐私泄露的情况。

但是在使用守护进程的过程中出现了一个很蛋疼的问题,在root权限下我们在Python中使用xml读取是完全没问题的,但是在使用守护进程后,却出现了一个毫无头绪的bug,报错信息如下:

Traceback (most recent call last):
File "-------------", line , in <module>(为保护隐私已经删去具体路径)
finish_str = ReadXmlTop()
File "--------", line , in ReadXmlTop dom = xml.dom.minidom.parse(sys.argv[])
File "/usr/lib/python2.7/xml/dom/minidom.py", line , in parse
from xml.dom import expatbuilder
File "/usr/lib/python2.7/xml/dom/expatbuilder.py", line , in <module>
from xml.parsers import expat
File "/usr/lib/python2.7/xml/parsers/expat.py", line , in <module>
from pyexpat import *
ImportError: /usr/lib/python2./lib-dynload/pyexpat.x86_64-linux-gnu.so: undefined symbol: XML_SetHashSalt

  很奇怪,我们虽然用到了minidom来读取xml,但是为什么root权限就可以,但是守护进程运行时就跪了呢?

  一开始我们参考了何涛的建议,认为可能是因为守护进程没有权限去读/lib这个文件夹。但是在加了权限后,事实表明,依然不对!

  那能是什么问题?在几经搜索与查找后,(在*上有一个类似问题但是并没有人回答...)终于在一个国外的论坛上找到了些许眉目,原因就是动态链接库的命名冲突!

  于是我们按照下面的方法在root权限下进行了检查:

ldd  /usr/lib/python2./lib-dynload/pyexpat.x86_64-linux-gnu.so

  发现显示如下

linux-vdso.so. => (0x00007fffba39e000)
libpthread.so. => /lib/x86_64-linux-gnu/libpthread.so. (0x00007fbb9306f000)
libc.so. => /lib/x86_64-linux-gnu/libc.so. (0x00007fbb92caa000)
libexpat.so. => /lib/x86_64-linux-gnu/libexpat.so. (0x00007fbb92a7f000)
/lib64/ld-linux-x86-.so. (0x00007fbb934a8000)

  其实能看出来这个动态链接库的指向路径确实是没有错误的,都是指向/lib/x86_64这个路径下的动态链接库,那么,究竟是哪里出了问题呢?

  我们思索很长时间,终于想到,我们现在是在root下查询的,结果当然是正确的,于是我们在守护进程里去查询,终于发现了一些端倪:

libexpat.so. => /opt/lampp/lib/libexpat.spo.1.5. 

  其余动态链接库的指向全部正确,唯有这个指向出了错误!错误就是在这里,因为laravel框架里自带的一些动态链接库与python的libexpat.so.1动态链接库命名相同,并且在默认条件下,守护进程的LD_LIBRARY_PATH是/opt/lampp/lib,所以这个守护进程优先选择了lampp自带的expat。

  但是由于lampp自带的expat是不兼容系统的expat的!(缺少一部分字段)所以没有办法执行xml的正确读取。

  错误知道了,该如何解决呢?我们起初是想,更改守护进程的LD_LIBRARY_PATH,使用:

export LD_LIBRARY_PATH =/lib

  但是不幸的是,不管我们如何更改,发现都没有办法成功更改守护进程的LD_LIBRARY_PATH,值永远是那个。在这过程中,我们还使用了一次ldconfig而让网站直接挂了...

  最后机智过人的小丽叔想到了一点,守护进程是一个特殊的进程而不是一个用户,这就意味着,它必须得起一个shell来更改它的环境变量才可以成功。之前我们都是直接使用终端让守护进程执行一些操作,而像更改环境变量这种操作他没办法直接实现。所以最后写了一个shell脚本来更改环境变量,然后守护进程执行shell脚本才成功。

  最后有一点要提示的是,在Linux上跑matlab,apache这些也会有类似的expat的不兼容问题,解决方法与上一致。这种方法只能说是将影响降到最低,但是还是会有Bug隐患,暂时还没有找到更好的解决方案。

上一篇:bzoj1132


下一篇:R 安装与环境配置