Alguma idéia de por que mod_wsgi cria um coredump no Apache httpd?

Question

Eu passei pela solução de problemas do mod_wsgi, mas não consegui encontrar uma resposta para o meu caso de falha de segmentação. Eu recebo o seguinte coredump quando o módulo mod_wsgi está integrado no meu servidor httpd Apache. O servidor sem mod_wsgi funciona bem.

• Apache http: 2.2.22
• mod_wsgi: 3.3
• Python: 2.6.7

Alguma idéia do que causa o coredump? Existe alguma coisa ou uma solução que eu possa tentar?

O dump principal:

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 ()

O binário httpd , compilado da origem. (Eu corri configure --prefix=... , isso é tudo)

> 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)

O módulo 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)

O executável do 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)

    

Answer 1

Na verdade, encontramos o problema, era um problema de dependência:

mod_wsgi.so usou uma versão específica de libpython2.6.so.1.0

ldd mod_wsgi.so libpython2.6.so.1.0 => /usr/lib64/libpython2.6.so.1.0 (0x00007f4c6dd87000)

vs. um diferente libpython2.6.so.1.0 usado pelo próprio binário python.

> ldd python
    libpython2.6.so.1.0 => /softntools/opt/Python-2.6/bin/../lib/libpython2.6.so.1.0 (0x00007f14730fc000)

Embora esses fossem os mesmos nomes de arquivos, esses arquivos não tinham o mesmo tamanho

> ls -l /softntools/opt/Python-2.6/bin/../lib/libpython2.6.so.1.0

deu 3710590 bytes

> 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

O que eu fiz para resolver o problema foi recompilar mod_wsgi alterando a variável LD_RUN_PATH para apontar para /softntools/opt/Python-2.6/lib/ e agora funciona.

    

Answer 2

Reconstrua tudo com símbolos de depuração e obtenha um backtrace melhor. Há obviamente um bug em algum lugar, mas sem um backtrace adequado você realmente não tem a esperança de encontrá-lo, ou até mesmo conseguir alguém para consertar isso para você (a menos que você realmente tenha sorte e alguém que recentemente teve o mesmo problema acontece) estar disponível para responder).