php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #38882 ldap_connect causes Segmentation fault
Submitted: 2006-09-19 13:42 UTC Modified: 2006-10-18 21:00 UTC
From: d dot wynne at ljmu dot ac dot uk Assigned:
Status: Closed Package: LDAP related
PHP Version: 4.4.4 OS: SuSE 10.1 x86_64
Private report: No CVE-ID: None
 [2006-09-19 13:42 UTC] d dot wynne at ljmu dot ac dot uk
Description:
------------
Thsi line causes Segmentation fault:

if (!($ldap = ldap_connect("localhost"))) {

./configure '--prefix=/usr' '--datadir=/usr/share/php' '--mandir=/usr/share/man' '--bindir=/usr/bin' '--includedir=/usr/include' '--sysconfdir=/etc' '--with-config-file-path=/etc' '--with-exec-dir=/usr/lib/php/bin' '--enable-debug' '--enable-inline-optimization' '--enable-memory-limit' '--enable-magic-quotes' '--enable-safe-mode' '--enable-sigchild' '--disable-ctype' '--with-mysql=/usr'  '--with-mssql=/usr' '--with-oci8=/net/oracle/10g'  '--disable-cgi' '--with-pear=/usr/share/php' '--with-openssl' '--with-ldap' '--with-apxs2=/usr/sbin/apxs2-prefork'

Some libraries come with both 32bit & 64bit versions:

openldap2-client-32bit-2.3.19-18
openldap2-client-2.3.19-18

I manually moved the /usr/lib64 libraries to /usr/lib. No way to use configure to do this. Rebuilt php 4.4.4 ( also tried 4.4.3 earlier ). Same result.






Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-09-19 13:48 UTC] tony2001@php.net
Which MySQL version do you use?
 [2006-09-19 14:04 UTC] d dot wynne at ljmu dot ac dot uk
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.
 [2006-09-19 14:33 UTC] tony2001@php.net
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.
 [2006-09-19 15:44 UTC] d dot wynne at ljmu dot ac dot uk
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.
 [2006-09-19 15:57 UTC] tony2001@php.net
>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.
 [2006-09-20 09:54 UTC] d dot wynne at ljmu dot ac dot uk
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.
 [2006-09-27 16:16 UTC] d dot wynne at ljmu dot ac dot uk
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.
 [2006-09-28 16:08 UTC] d dot wynne at ljmu dot ac dot uk
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.
 [2006-09-28 16:16 UTC] tony2001@php.net
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.


 [2006-09-29 08:53 UTC] d dot wynne at ljmu dot ac dot uk
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)
 [2006-09-29 09:13 UTC] tony2001@php.net
Does valgrind show you anything useful?
A segfault somewhere in OpenLDAP doesn't look like PHP problem so far.
 [2006-09-29 10:29 UTC] d dot wynne at ljmu dot ac dot uk
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 ?
 [2006-09-29 10:43 UTC] tony2001@php.net
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.
 [2006-09-29 14:00 UTC] d dot wynne at ljmu dot ac dot uk
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.
 [2006-09-29 14:06 UTC] tony2001@php.net
>a) The PHP build fails if I do
>--enable-experimental-zts

Please elaborate.
 [2006-09-29 14:44 UTC] d dot wynne at ljmu dot ac dot uk
.....
 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'
 [2006-09-29 14:45 UTC] tony2001@php.net
`make clean` is required.
 [2006-09-29 15:04 UTC] d dot wynne at ljmu dot ac dot uk
OK, Built & installed. Presumably now there's some new options or statements to the /usr/bin/php CLI script with the ldap_connect statement.
 [2006-10-02 22:11 UTC] tony2001@php.net
See also bug #38819 and the solution inside.
Let us know if it works for you.
 [2006-10-04 14:49 UTC] d dot wynne at ljmu dot ac dot uk
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.
 [2006-10-04 15:13 UTC] tony2001@php.net
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

 [2006-10-09 12:12 UTC] d dot wynne at ljmu dot ac dot uk
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.
 [2006-10-18 21:00 UTC] tony2001@php.net
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.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Mar 19 10:01:30 2024 UTC