[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

apache php4-imap Segmentation fault (help needed)



Hi.
On one of my servers, apache segfaults when php4 loads the imap.so module.
I have a few servers with similar versions, and only one of the servers 
experiences the segfault. 

I am unable to discover the cause of the segfault, and would really appreciate 
some advice in how to locate it.

What I have done:

I have set "LogLevel debug" in "/etc/apache/httpd.conf"

When commenting out the line "extension=imap.so" from  
"/etc/php4/apache/php.ini", apache starts and works very well.
# tail -2 /var/log/apache/error.log
[Mon Apr 21 00:31:46 2003] [info] mod_unique_id: using ip addr 127.0.0.1
[Mon Apr 21 00:31:47 2003] [info] created shared memory segment #4194305

When uncommenting the line "extension=imap.so", I use the following to do a 
strace of apache "strace apache -X 2> /tmp/apache.strace"
# tail -1 /var/log/apache/error.log
[Mon Apr 21 00:42:34 2003] [info] mod_unique_id: using ip addr 127.0.0.1
# tail /tmp/apache.strace
open("/etc/protocols", O_RDONLY)        = 5
fcntl64(5, F_GETFD)                     = 0
fcntl64(5, F_SETFD, FD_CLOEXEC)         = 0
fstat64(5, {st_mode=S_IFREG|0644, st_size=1748, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x40233000
read(5, "# /etc/protocols:\n# $Id: protoco"..., 4096) = 1748
close(5)                                = 0
munmap(0x40233000, 4096)                = 0
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++

On another server, that doesn't experience the segfault, the following is 
straced instead of the segfault:
open("/etc/protocols", O_RDONLY)        = 5
fcntl64(5, F_GETFD)                     = 0
fcntl64(5, F_SETFD, FD_CLOEXEC)         = 0
fstat64(5, {st_mode=S_IFREG|0644, st_size=1748, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0
x40245000
read(5, "# /etc/protocols:\n# $Id: protoco"..., 4096) = 1748
close(5)                                = 0
munmap(0x40245000, 4096)                = 0
brk(0)                                  = 0x80dd000
brk(0x80de000)                          = 0x80de000
brk(0)                                  = 0x80de000
brk(0x80df000)                          = 0x80df000
brk(0)                                  = 0x80df000
...

The two servers where php4-imap behave differently run mainly stable, but with  
apache and php4 from unstable. Both with 2.4 kernels.
On the machine with the segfault:
# cat /proc/version
Linux version 2.4.18-686-smp (herbert@gondolin) (gcc version 2.95.4 20011002 
(Debian prerelease)) #1 SMP Sun Apr 14 12:07:19 EST 2002
# dpkg -l "apache*"  | grep "^ii"
ii  apache         1.3.27-0.1     Versatile, high-performance HTTP server
ii  apache-common  1.3.27-0.1     Support files for all Apache webservers
arjuna:/etc/php4/apache# dpkg -l "php4*"  | grep "^ii"
ii  php4           4.2.3-13       A server-side, HTML-embedded scripting langu
ii  php4-imap      4.2.3-13       IMAP module for php4
ii  php4-pear      4.2.3-13       PEAR - PHP Extension and Application Reposit
ii  php4-pear-log  1.6.0-1        Log module for PEAR
ii  php4-pgsql     4.2.3-1        PostgreSQL module for php4

On the machine without the segfault:
cat /proc/version
Linux version 2.4.20-586tsc (herbert@gondolin) (gcc version 2.95.4 20011002 
(Debian prerelease)) #1 Sat Jan 11 20:01:58 EST 2003
# dpkg -l "apache*"  | grep "^ii"
ii  apache         1.3.27-0.1     Versatile, high-performance HTTP server
ii  apache-common  1.3.27-0.1     Support files for all Apache webservers
ii  apache-doc     1.3.26-0woody3 Apache webserver docs
h2o:/etc/php4/apache# dpkg -l "php4*"  | grep "^ii"
ii  php4           4.2.3-13       A server-side, HTML-embedded scripting langu
ii  php4-apc       1.1.0pl1-9     Caches PHP scripts to get them loaded much f
ii  php4-cgi       4.2.3-13       A server-side, HTML-embedded scripting langu
ii  php4-imap      4.2.3-13       IMAP module for php4
ii  php4-ldap      4.2.3-13       LDAP module for php4
ii  php4-pear      4.2.3-13       PEAR - PHP Extension and Application Reposit
ii  php4-pear-log  1.6.0-1        Log module for PEAR
ii  php4-pgsql     4.2.3-1        PostgreSQL module for php4

And finally a look at how this imap.so file is linked:
On the machine with the segfault:
# ldd /usr/lib/php4/20020429/imap.so
        libcrypto.so.0.9.7 => /usr/lib/i686/cmov/libcrypto.so.0.9.7 
(0x40016000)
        libssl.so.0.9.7 => /usr/lib/i686/cmov/libssl.so.0.9.7 (0x40108000)
        libc-client.so.2003debian => /usr/lib/libc-client.so.2003debian 
(0x40137000)
        libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x401ed000)
        libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x401fe000)
        libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x40253000)
        libcom_err.so.2 => /lib/libcom_err.so.2 (0x40264000)
        libc.so.6 => /lib/libc.so.6 (0x40267000)
        libdl.so.2 => /lib/libdl.so.2 (0x40377000)
        libpam.so.0 => /lib/libpam.so.0 (0x4037a000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x40382000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

On the machine without the segfault:
# ldd /usr/lib/php4/20020429/imap.so
        libcrypto.so.0.9.7 => /usr/lib/i686/cmov/libcrypto.so.0.9.7 
(0x4001c000)
        libssl.so.0.9.7 => /usr/lib/i686/cmov/libssl.so.0.9.7 (0x4010e000)
        libc-client.so.2003debian => /usr/lib/libc-client.so.2003debian 
(0x4013d000)
        libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x401f3000)
        libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x40205000)
        libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x4025a000)
        libcom_err.so.2 => /lib/libcom_err.so.2 (0x4026a000)
        libc.so.6 => /lib/libc.so.6 (0x4026d000)
        libdl.so.2 => /lib/libdl.so.2 (0x4037d000)
        libpam.so.0 => /lib/libpam.so.0 (0x40380000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x40388000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

*************
Can you please give me some advice as to how I can track this down?
Or maybe some of the above information should be elaborated or reveal some 
hint I fail to see?

Sincerely 
Jørgen H. Fjeld



Reply to: