我经历了mod_wsgi的故障排除，但无法find我的情况下分段故障的答案。 当模块mod_wsgi集成到我的Apache httpd服务器中时，我得到了下面的coredump。 没有mod_wsgi的服务器运行良好。
任何想法是什么导致coredump？ 有什么事情可以尝试吗？
核心转储：
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)
事实上，我们发现这个问题，这是一个依赖性问题：
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）
与python二进制本身使用的不同的libpython2.6.so.1.0 。
> 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_PATHvariables指向/softntools/opt/Python-2.6/lib/来重新编译mod_wsgi，现在它可以工作。
用debugging符号重build所有东西，并获得更好的回溯。 在某个地方有一个明显的错误，但是没有一个正确的回溯，你并不是真的有希望find它，甚至让别人来为你修复它（除非你真的走运了，而最近有一个问题的人会发生可以回答）。