python coredump的经历[转]

378

　　最近在写python，用了email/sqlite3/mysql/poplib/等东东。程序写完后进行压力，发现无端端退出了，把ulimit -c 设置成比较大的数字（在linux下默认是0 ），让它产生core文件。跟踪了N个core文件，都是在malloc/free之类的地方，感觉就是多线程问题，冲乱了内存。但是隔着一个python解析器，难以跟踪，花了两三天时间都没找到问题，郁闷了好久。Python都会coredump？用了python好久的高手都不解。

最后没办法，只能“拆卸”来找问题，依次拆了解析mail部分、pop部分、mysql部分，都照样core，最后拆sqlite3，不core了。python2.5可是自称自带sqlite3的啊！！居然有问题。详细研究后，发现python2.5所谓自带sqlite3，其实只是自带了sqlite3的封装接口，还是需要下载sqlite3.4的包进行安装，然后在python2.5的setup.py中修订sqlite3的路径（如果不是默认路径安装），才会生成_sqlite3.so。而sqlite3在linux下编译默认是不支持多线程安全！在windows下反而默认是支持的。GOD!!! 增加多线程选项：
--enable-threadsafe --enable-cross-thread-connections
　　目前跑得很稳定，不再出现coredump现象。

惨痛的coredump经历，差点打击了我对python的信心！！