Which MySQL version do you use?

mysql-client-5.0.18-16
mysql-devel-5.0.18-16
mysql-shared-5.0.18-16

The client libraies are only located at /usr/lib64/mysql, so again I had to copy these to /usr/lib to get configure to see them

mysql_* functions work fine, and using PEAR too. Our MySQL server is actually on a different host so no mysql-server packages on this host.

The reason of this problem is YaSSL, which is used in 5.0.x versions of MySQL. AFAIK it has been fixed in latest version, but I'm not 100% sure.
Anyway, it's not PHP problem.

Seems a bit strange that all the mysql_* functions work OK, and only when you do an ldap_connect the problem with mysql 5.0.x arises.

Anyway the latest version of MySQL 5 seems to be  5.0.24. Would this be worth trying or is there a newer version which has a better chance.

Appeciate you help as it seems not to be an issue with PHP, but external libraries.

>Seems a bit strange that all the mysql_* functions work
> OK, and only when you do an ldap_connect the problem with >mysql 5.0.x arises.
There is no problem as long as no OpenSSL functions are used.
YaSSL and OpenSSL have conflicting names inside, so what you see is just a clash between them.

>Would this be worth trying or is there a newer version
> which has a better chance.
Yes, I think it would.

Upgraded all 3 MySQl packages to version 5.0.24a. Re-built php-4.4.4 from scratch by deleting top level directoty and re-extracting tar file.

Ran configure as beforw. Built no problem.

make install

/etc/init.d/apache2 restart

Same problem when using ldap_connect:


[Wed Sep 20 10:38:25 2006] [notice] child pid 21744 exit signal Segmentation fault (11)

I can try and get a backtrace if you think it would help. Never done this before but the instructions seem straightforward.

Right I've now compiled MySQL from source code. I'm using the mysql-5.0.18-src RPM as this matches exacly the binary RPM that comes with SuSE 10.1. Configure MySQL:

./configure --prefix=/usr --without-yassl  --enable-thread-safe-client --with-gnu-ld --without-server  --with-named-curses-libs=/usr/lib64/curses/libcurses.a

--without-yassl I believe is the significant part. Built & installed  Checked the libraries & header files are in the right place:

ldconfig

Re-built php from scratch. Configure as before. Installed & restarted Apache2. Same result.

Segmentation fault on ldap_connect. Please help.

Now I've implicitly rebuilt php-4.4.4 --without-mysql. Installed and tested that indeed MySQL connections fail, and they do.

Still Segmentation fault on ldap_connect.

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

This is my php-4.4.4 --without-mysql variant. The production apache module I normally use obviously has MySQL support

Using browser to test MySQL connections

PEAR

DB Error: extension not found

Standard

Fatal error: Call to undefined function: mysql_connect() in /home/ftpserver/www/homepage/staff/cmsdwynn/php/mysqlconn.php on line 2

Backtrace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47225668576928 (LWP 31755)]
0x00002af39405c481 in ldap_unbind_ext () from /usr/lib64/libldap-2.3.so.0

(gdb)bt
#0  0x00002af39405c481 in ldap_unbind_ext () from /usr/lib64/libldap-2.3.so.0
#1  0x00002af396202c9e in _close_ldap_link (rsrc=<value optimized out>)
    at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/ldap/ldap.c:175
#2  0x00002af3962c46fe in list_entry_destructor (ptr=<value optimized out>)
    at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_list.c:177
#3  0x00002af3962c403a in zend_hash_del_key_or_index (ht=0x2af396449268, 
    arKey=0x0, nKeyLength=0, h=6, flag=<value optimized out>)
    at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_hash.c:529
#4  0x00002af3962c4907 in _zend_list_delete (id=<value optimized out>)
    at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_list.c:56
#5  0x00002af3962b4a76 in _zval_ptr_dtor (zval_ptr=0x555555931330)
    at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_execute_API.c:289
#6  0x00002af3962c2688 in zend_hash_clean (ht=0x5555559030e8)
    at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_hash.c:584
#7  0x00002af3962d2d69 in execute (op_array=0x555555911b98)
    at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_execute.c:1736
#8  0x00002af3962d0a29 in execute (op_array=0x5555558e3ff8)
    at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_execute.c:1719
#9  0x00002af3962bd2a9 in zend_execute_scripts (type=8, retval=0x0, 
    file_count=3) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend.c:934
#10 0x00002af39628ee57 in php_execute_script (primary_file=0x7fff16f175d0)
    at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/main/main.c:1752
#11 0x00002af3962dafc1 in php_handler (r=0x5555558e81d8)
    at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/sapi/apache2handler/sapi_apache2.c:581
#12 0x000055555558c6ba in ap_run_handler () from /usr/sbin/httpd2-prefork
#13 0x000055555558faa2 in ap_invoke_handler () from /usr/sbin/httpd2-prefork
#14 0x000055555559a1c8 in ap_process_request () from /usr/sbin/httpd2-prefork
#15 0x0000555555597409 in ap_register_input_filter ()
   from /usr/sbin/httpd2-prefork
#16 0x0000555555593772 in ap_run_process_connection ()
   from /usr/sbin/httpd2-prefork
#17 0x000055555559dc09 in ap_graceful_stop_signalled ()
   from /usr/sbin/httpd2-prefork
#18 0x000055555559de0e in ap_graceful_stop_signalled ()
   from /usr/sbin/httpd2-prefork
#19 0x000055555559e911 in ap_mpm_run () from /usr/sbin/httpd2-prefork
#20 0x0000555555579cb8 in main () from /usr/sbin/httpd2-prefork
(gdb)

Does valgrind show you anything useful?
A segfault somewhere in OpenLDAP doesn't look like PHP problem so far.

Not used valgrind at all, but I've done a bit of searching & I've found someone else with exactly the same problme as I'm having. The exact version of PHP is not mentioned, but the same backtrace including:

#0  0x00002aaaab1f2151 in ldap_unbind_ext () 
from /usr/lib64/libldap-2.3.so.0

is. Also it's 64 bit linux and the same version of Apache ( 2.2.0 ). He claims that the code works using the PHP CLI. I have tested this with:


#! /usr/bin/php
<?php
$ldapServer = "bydc1.jmu.ac.uk";
echo "<p>Connecting</p>\n";
$ds=ldap_connect($ldapServer);
echo "<p>Disconnecting</p>\n";
ldap_close($ds);
?>

and indeed it does. No Segmentatio fault.

Does that mean that PHP / MySQL / LDAP are all red herringd and the culprit could be Apache, as the CLI version works, and the problem only occurs when running it through a browser ?

Well, you can also try to compile PHP CLI with --enable-experimental-zts and see if it works for you OR (I'd prefer this one) use Apache 1.x for tests.

Now I'm stuck:

a) The PHP build fails if I do
--enable-experimental-zts

b) SuSE 10.1 only ships with apache2 binary RPM's. I downloaded apache 1.3 source and compiled / installed  & ran, but httpd just dies, no errors in the loge either. In any case a downgrade to apache 1.3 isn't an option as I have other apache 2.x only modules that I besides PHP.

c) No updates on the SuSE update server for either apache2 or openldap.

Problem appears to point to OpenLDAP, so all I can think of next is to compile / install the latest build. Maybe this is an anomaly with 64 bit machines, which is why it's reporing is not more widespread.

>a) The PHP build fails if I do
>--enable-experimental-zts

Please elaborate.

.....
 Zend/zend_sprintf.lo Zend/zend_ini.lo Zend/zend_qsort.lo Zend/zend_multibyte.lo
 Zend/zend_strtod.lo Zend/zend_execute.lo sapi/cli/php_cli.lo sapi/cli/getopt.lo
 main/internal_functions_cli.lo -lcrypt -lcrypt -lsybdb -lldap -llber -lresolv -
lm -ldl -lnsl -lssl -lcrypto -ldl -ldl -lm -lnsl -lirc -lclntsh -lcrypt -lcrypt 
 -o sapi/cli/php
ext/standard/info.lo: In function `php_info_print_table_header':
/home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/standard/info.c:756: undefined refere
nce to `ts_resource_ex'
ext/standard/info.lo: In function `php_info_print_table_row':
/home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/standard/info.c:800: undefined refere
nce to `ts_resource_ex'
ext/standard/info.lo: In function `php_print_gpcse_array':
/home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/standard/info.c:119: undefined refere
nce to `executor_globals_id'
ext/standard/info.lo: In function `php_info_write_wrapper':
/home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/standard/info.c:67: undefined referen
ce to `ts_resource_ex'
ext/standard/info.lo: In function `php_print_info':
/home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/standard/info.c:624: undefined refere
nce to `executor_globals_id'
/home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/standard/info.c:554: undefined refere
nce to `sapi_globals_id'

`make clean` is required.

OK, Built & installed. Presumably now there's some new options or statements to the /usr/bin/php CLI script with the ldap_connect statement.

See also bug #38819 and the solution inside.
Let us know if it works for you.

Sticking with:

openldap2-2.3.19
php 4.4.4

Certainly the introduction of ldap:// in front of the hostname stopped the Segmentatio fault on the ldap_connect. The script still Segmentation faulted later on as there are lots of ldap_* functions.

I also was unsure of where to put:

-DLDAP_DEPRECATED=1

In php 4.4.4 there is no Makefile in ext/ldap, so in config.m4:

CPPFLAGS="$CPPFLAGS -I$LDAP_INCDIR"

changed to:

CPPFLAGS="$CPPFLAGS -I$LDAP_INCDIR -DLDAP_DEPRECATED=1"

Still Segfaults, but looking at the output of make the -DLDAP_DEPRECATED=1 didn't seem to be getting passed.

Instead changed the "top-level" Makefile, there are 3 "libtool" lines, and changed -DLDAP_DEPRECATED to -DLDAP_DEPRECATED=1

 $(LIBTOOL) --mode=compile $(CC)  -D_FORTIFY_SOURCE=2 -DLDAP_DEPRECATED=1 -I/usr/include/apache2-prefork  -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -I/usr/include   -I/usr/include/apr-1  -Isapi/apache2handler/ -I/home/cmstechs/cmsdwynn/SuSE/php-4.4.4/sapi/apache2handler/ $(COMMON_FLAGS) $(CFLAGS_CLEAN) $(EXTRA_CFLAGS)  -c /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/sapi/apache2handler/sapi_apache2.c -o sapi/apache2handler/sapi_apache2.lo
sapi/apache2handler/apache_config.lo: /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/sapi/apache2handler/apache_config.c
        $(LIBTOOL) --mode=compile $(CC)  -D_FORTIFY_SOURCE=2 -DLDAP_DEPRECATED=1 .....

Again still segfaults.

Apply this patch, run make clean && ./buildconf && ./config.nice && make

Index: ext/ldap/config.m4
===================================================================
RCS file: /repository/php-src/ext/ldap/config.m4,v
retrieving revision 1.26.2.8.2.1
diff -u -p -d -r1.26.2.8.2.1 config.m4
--- ext/ldap/config.m4  3 Nov 2005 20:41:56 -0000       1.26.2.8.2.1
+++ ext/ldap/config.m4  4 Oct 2006 15:12:48 -0000
@@ -23,7 +23,7 @@ PHP_ARG_WITH(ldap,for LDAP support,

 if test "$PHP_LDAP" != "no"; then

-  PHP_NEW_EXTENSION(ldap, ldap.c, $ext_shared)
+  PHP_NEW_EXTENSION(ldap, ldap.c, $ext_shared,,-DLDAP_DEPRECATED=1)

   if test "$PHP_LDAP" = "yes"; then
     for i in /usr/local /usr; do

That worked a charm, I had to do:

./buildconf --force

if, at some later stage I want to re-build PHP --with-gd=/usr for example, would running configure "destroy" the ldap fix ? if so, how can I re-instate it.
 
Many many thanks for your help.

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

>would running configure "destroy" the ldap fix
No, you can destroy it only by reverting the patch and running ./buildconf again.