我尝试了 mod_wsgi 的故障排除，但找不到解决分段错误问题的答案。当模块mod_wsgi集成到我的 Apache httpd 服务器中时，我得到了以下核心转储。没有它的服务器mod_wsgi运行良好。
- Apache httpd：2.2.22
- mod_wsgi： 3.3
- Python：2.6.7
知道是什么原因导致核心转储吗？有什么方法或解决方法可以尝试吗？
核心转储：
Program terminated with signal 11, Segmentation fault.
#0 0x00007fe06c39d206 in wsgi_python_init () from /remote/projects1/pdrtke/install/httpd-2.2.22/modules/mod_wsgi.so
#1 0x00007fe06c3aadb5 in wsgi_hook_child_init () from /remote/projects1/pdrtke/install/httpd-2.2.22/modules/mod_wsgi.so
#2 0x00000000004424db in ap_run_child_init ()
#3 0x000000000047ea35 in child_main ()
#4 0x000000000047ef26 in make_child ()
#5 0x000000000047f198 in perform_idle_server_maintenance ()
#6 0x000000000047f67b in ap_mpm_run ()
#7 0x0000000000429361 in main ()
httpd从源代码编译的二进制文件。（我运行了，configure --prefix=...仅此而已）
> file httpd
httpd: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.4, dynamically linked (uses shared libs), not stripped
> ldd httpd
linux-vdso.so.1 => (0x00007fffdc5ff000)
libm.so.6 => /lib64/libm.so.6 (0x00007f33ef7fe000)
libaprutil-1.so.0 => /remote/projects1/pdrtke/install/httpd-2.2.22/lib/libaprutil-1.so.0 (0x00007f33ef5d4000)
libexpat.so.1 => /lib64/libexpat.so.1 (0x00007f33ef3aa000)
libapr-1.so.0 => /remote/projects1/pdrtke/install/httpd-2.2.22/lib/libapr-1.so.0 (0x00007f33ef172000)
librt.so.1 => /lib64/librt.so.1 (0x00007f33eef69000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f33eed2e000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f33eeb11000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f33ee90d000)
libc.so.6 => /lib64/libc.so.6 (0x00007f33ee5af000)
/lib64/ld-linux-x86-64.so.2 (0x00007f33efa54000)
模块WSGI：
> file mod_wsgi.so
mod_wsgi.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
> ldd mod_wsgi.so
linux-vdso.so.1 => (0x00007fffb8f0e000)
libpython2.6.so.1.0 => /usr/lib64/libpython2.6.so.1.0 (0x00007f4c6dd87000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f4c6db69000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f4c6d965000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007f4c6d762000)
libm.so.6 => /lib64/libm.so.6 (0x00007f4c6d50b000)
libc.so.6 => /lib64/libc.so.6 (0x00007f4c6d1ad000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4c6e37b000)
Python 可执行文件：
> file python
python: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.4, dynamically linked (uses shared libs), not stripped
> ldd python
linux-vdso.so.1 => (0x00007fff6a1ff000)
libpython2.6.so.1.0 => /softntools/opt/Python-2.6/bin/../lib/libpython2.6.so.1.0 (0x00007f14730fc000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f1472edf000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f1472cdb000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007f1472ad8000)
libm.so.6 => /lib64/libm.so.6 (0x00007f1472882000)
libc.so.6 => /lib64/libc.so.6 (0x00007f1472524000)
/lib64/ld-linux-x86-64.so.2 (0x00007f14733b0000)
答案1
事实上，我们发现了这个问题，这是一个依赖性问题：
mod_wsgi.so使用特定版本的libpython2.6.so.1.0
ldd mod_wsgi.so libpython2.6.so.1.0 => /usr/lib64/libpython2.6.so.1.0 (0x00007f4c6dd87000)
libpython2.6.so.1.0与Python 二进制文件本身所使用的不同。
> ldd python
libpython2.6.so.1.0 => /softntools/opt/Python-2.6/bin/../lib/libpython2.6.so.1.0 (0x00007f14730fc000)
尽管这些文件名相同，但文件大小却不同
> ls -l /softntools/opt/Python-2.6/bin/../lib/libpython2.6.so.1.0
给了 3710590 字节
> ls -l /usr/lib64/libpython2.6.so.1.0 3:33PM
-rw-r--r-- 1 root root 1594904 May 5 2010 /usr/lib64/libpython2.6.so.1.0
我为解决这个问题所做的是通过改变 LD_RUN_PATH 变量来重新编译 mod_wsgi，/softntools/opt/Python-2.6/lib/现在它可以工作了。
答案2
使用调试符号重建所有内容，并获得更好的回溯。显然某个地方有错误，但如果没有正确的回溯，您实际上不可能找到它，甚至无法让其他人为您修复它（除非您真的很幸运，并且最近遇到过完全相同问题的人恰好可以回答）。