What was the configure line used to configure PHP?
And are you sure you're linking both apache2 and PHP with _same_ SSL libs?

yes i'm sure they use the same openssl library since i've complied both openssl, apache2 and php from source.

configure for mod_php (php as apache DSO module) :
./configure --without-readline --with-pam --with-openssl -with-gdbm=/usr --with-mysql=/usr --with-gd=/usr --with-pspell --with-tiff-dir=/usr --with-jpeg-dir=/usr --with-pdflib=/usr --with-ttf --with-t1lib --with-zlib --with-zlib-dir=/usr/lib --with-exec-dir=/usr/bin --with-apxs2=/usr/sbin/apxs2 --with-imap --with-imap-ssl --with-mcrypt --with-mhash --disable-posix-threads --with-java=/opt/sun-jdk-1.4.1.02 --prefix=/usr --with-bz2 --enable-ftp --enable-force-cgi-redirect --enable-discard-path --enable-mime-magic --enable-wddx --enable-dbase --with-zlib=yes --with-iconv --enable-bcmath  --enable-sysvsem --enable-exif --enable-sysvshm  --enable-sockets --enable-calendar --enable-trans-sid  --enable-safe-mode --enable-versioning --enable-track-vars  --enable-inline-optimization --with-config-file-path=/etc/php4 --with-sablot=/usr --enable-xslt --with-xslt-sablot --with-xmlrpc --with-gettext -with-db=/usr

Your configure line contains couple of options that are 
really unnecessary, for example these:

-with-db (use --enable-dba)
--enable-versioning (Only needed if you have php3 installed too and that doesn't support Apache2, so..)
--enable-track-vars (doesn't exist), --enable-inline-optimization (might cause problems)
--without-readline (not enabled by default anyway)
--disable-posix-threads (why?)
--enable-force-cgi-redirect (Only used for CGI build)
--enable-discard-path (Only used for CGI builds)

And what MPM is used for Apache2?
Remove those options mentioned above + --enable-debug and try again. ("rm -f config.cache" first!)

If it still crashes, provide the backtrace.

I did some more tests:
 - enabling your suggested configure cleanups didn't help (=the problem is still there)...thanks anyway (i was using them since previous 4.2.x release)
 - tested the same setup with apache 1.3.27+mod_ssl : it works fine with php both enabled and disabled... so it seems to be only confined to apache2+ssl+php
 - MPM used for apache2 is "prefork" ... should I change it?
 - php 4.3.1 and 4.3.2 both show the issue

i'm going to try to obtain a backtrace using httpd -X with php in debug mode. btw, will this work (=will it produce a backtrace) even if the site is not using any php script at all ?

No, don't change the MPM.
And yes, you will get a backtrace always, it's not really
PHP related thing.

# gdb httpd
(gdb) run -X -DSSL
..then access the page causing the crash..
(gdb) bt

Try reduce the configure options to the bare minimum
first. Then if you don't get any segfaults, try every
excluded option one by one to see which one is causing 
this.

And for the backtrace you just need to keep pressing 
'enter' until it gets there..the first couple of screens 
gdb is loading the symbols from every linked library, you 
can ignore it..

i'm doing some more tests... an interesting thing: on Redhat 9.0 it works fine (openssl 0.9.7a, php 4.2.2, apache 2.0.40 - both stock versions) . I'm trying to figure out where the problem is. I'll let you know, probaly there is something in my setup which causes php or apache to behave strangely.

alessandro

finally, i've found the problem: compiling php 4.3.2 with --with-mysql=/path-to-mysql staically linked is the culprit.
The problem can be avoided using --with-mysql and so using PHP's built-in (but obsolete) mysql interface or using: --with-mysql=shared,/path-to-mysql and then enabling php_mysql.so in php.ini

Tests had been accomplished on three machines:
a) gentoo linux 1.2: glibc 2.2.5, php 4.3.2, apache 2.0.45/46, mysql 4.0.12, openssl 0.9.6j

b) gentoo linux 1.4rc4: glibc 2.3.1, php 4.3.2, apache 2.0.46, mysql 4.0.13, openssl 0.9.7b

c) redhat 9: php 4.2.2, apache 2.0.40, openssl 0.9.7a, mysql-4.0.10

alessandro

That sounds odd. And as you're not running Apache2 as threaded (worker, or whatever that MPM was again), it shouldn't be thread-safety issue either.

Could you check what libmysqlclient.so is linked with
on those systems? Output of:

# ldd libmysqlclient.so

And FYI: the bundled mysql library is far from obsolete.
(it works, doesn't it? :)

output of ldd libmysqlclient.so for each platform (cfr. my previous comment) :

rh9)
    libz.so.1 => /usr/lib/libz.so.1 (0x40053000)
    libcrypt.so.1 => /lib/libcrypt.so.1 (0x40061000)
    libnsl.so.1 => /lib/libnsl.so.1 (0x4008e000)
    libm.so.6 => /lib/tls/libm.so.6 (0x400a4000)
    libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
    /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

gentoo 1.2)
    libz.so.1 => /usr/lib/libz.so.1 (0x40047000)
    libcrypt.so.1 => /lib/libcrypt.so.1 (0x40055000)
    libnsl.so.1 => /lib/libnsl.so.1 (0x40082000)
    libm.so.6 => /lib/libm.so.6 (0x40097000)
    libssl.so.0.9.7 => /usr/lib/libssl.so.0.9.7 (0x400b8000)
    libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0x400e6000)
    libc.so.6 => /lib/libc.so.6 (0x401d9000)
    libdl.so.2 => /lib/libdl.so.2 (0x402fc000)
    /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

gentoo 1.4)
    libz.so.1 => /usr/lib/libz.so.1 (0x40052000)
    libcrypt.so.1 => /lib/libcrypt.so.1 (0x40060000)
    libnsl.so.1 => /lib/libnsl.so.1 (0x4008d000)
    libm.so.6 => /lib/libm.so.6 (0x400a1000)
    libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x400c3000)
    libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x400f1000)
    libc.so.6 => /lib/libc.so.6 (0x401b1000)
    libdl.so.2 => /lib/libdl.so.2 (0x402da000)
    /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

i'm also investigating more things... let me know if you need to me to test some specific items

alessandro

more news: i've jsut tried recompiling mysql without openssl support on both the gentoo platforms (as of RH9, cfr ldd output in my previous comment) and php now work as expected with --with-mysql=/usr. So the whole things seems to be related to openssl support in MySQL. Is still the whole thing pertinent to php or should I ask mysql people ?

alessandro

Yes, just what I expected. It's not really our problem,
most likely mysql does some fancy init stuff with openssl,
or you just mix two different openssl versions.

Try compiling everything from sources with debug symbols, I guess mysql and openssl have some --enable-debug switch too. Then you'll get better GDB backtrace.

sniper: I think there still is something related to PHP itself. On both the three machine using the same version of mysql (with openssl support enabled), openssl and php with apache 1.3.x have no problem at all. Also, both apache1 and apache2 without php work fine with mysql+ssl. Problem is somehow related to the apache2 sapi in php...maybe it is not php own fault but there is a weird relation between them.

let me know if I can help with more tests and/or providing more info.

alessandro

updating the uw-imap client and the php build options with the latest one from gentoo solved the problem. don't know what it was really related to, it is really difficult for me to track it down dut to the large amount of combinations of packages and related options.

it was probaly related to a wrong set of compile options and/or a combo of compile options and obsolete libraries with had problems with ssl.

please consider the bug one "closed" or "invalid".
if in the near future i'll find out more data about it i'll report it here.

thanks for your help
alessandro