|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #38819 segfault in ldap_get_entries()
Submitted: 2006-09-14 01:29 UTC Modified: 2007-02-28 15:04 UTC
Avg. Score:4.5 ± 0.5
Reproduced:4 of 4 (100.0%)
Same Version:2 (50.0%)
Same OS:1 (25.0%)
From: madcoder at gmail dot com Assigned:
Status: Closed Package: LDAP related
PHP Version: 5.1.6 OS: 2.6.17-gentoo linux amd64
Private report: No CVE-ID: None
 [2006-09-14 01:29 UTC] madcoder at gmail dot com
I'm getting a segmentation fault when calling ldap_get_entries() after an ldap search.  I get no errors after any of the function calls prior to ldap_get_entries() (as suggested by ldap_errno() == 0).

Running a similar ldapsearch command line query returns results as expected.

A similar configuration on another linux installation of the same version works with no problems.  The major difference between those two servers is the CPU (the working one is an Intel P4, the one that is segfaulting is an AMD 64-bit Athlon XP)

Reproduce code:
$_SERVER['ldap'] = ldap_connect("ldap://server.domain");
ldap_set_option($_SERVER['ldap'], LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($_SERVER['ldap'], LDAP_OPT_REFERRALS, 0);
ldap_bind($_SERVER['ldap'], 'user@domain', 'password');
$r = ldap_search($_SERVER['ldap'], 'dc=fq,dc=domain,dc=name', '(sAMAccountName=someUser)');
echo "done searching\n";
$info = ldap_get_entries($_SERVER['ldap'], $r);
echo "done fetching\n";

Expected result:
"done fetching\n" should be printed, and $info should contain an array of entries returned from the LDAP server.

Actual result:
# php -e test.php
done searching
Segmentation fault (core dumped)
# gdb php core
GNU gdb 6.4
(gdb) bt
#0  0x00002aaaac8cbf4b in ?? ()
#1  0xa6e95d9926b7ed00 in ?? ()
#2  0x0000555555dbe260 in ?? ()
#3  0x0000555555de16c0 in ?? ()
#4  0x00005555556a92b5 in ?? ()
#5  0x000000000000000f in ?? ()
#6  0x0000000000000001 in ?? ()
#7  0x000000000000000f in ?? ()
#8  0x00002aaaaea76cf0 in ?? ()
#9  0x0000000000000003 in ?? ()
#10 0x0000000000000000 in ?? ()

(I realize this backtrace is not helpful...  I've tried re-emerging the php ebuild several times with the debug USE flag enabled, and it seems all the debug info is still being stripped from the binaries.  I will try compiling from source with the appropriate options and reply with a more useful backtrace)


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2006-09-14 08:28 UTC]
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 for *NIX and 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-18 23:38 UTC] madcoder at gmail dot com
Sorry for the delay (I had to fix an error with gdb not generating backtraces on AMD64...)  Here's the backtrace:

(gdb) run
Starting program: /usr/bin/php -e test.php
[Thread debugging using libthread_db enabled]
[New Thread 47773184727840 (LWP 28424)]
done searching

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47773184727840 (LWP 28424)]
0x00002b730d78de44 in ldap_count_values (vals=0x55e99220) at getvalues.c:153
153     getvalues.c: No such file or directory.
        in getvalues.c
(gdb) bt
#0  0x00002b730d78de44 in ldap_count_values (vals=0x55e99220) at getvalues.c:153
#1  0x00005555556a25c0 in zif_ldap_get_entries (ht=1441370656, return_value=0x555555e987a8, return_value_ptr=0x0,
    this_ptr=0x0, return_value_used=1438266616, tsrm_ls=0x555555e9cc60)
    at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/ext/ldap/ldap.c:1068
#2  0x0000555555890d35 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fff9f13efb0, tsrm_ls=0x555555ba4450)
    at zend_vm_execute.h:200
#3  0x0000555555899c6a in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0x7fff9f13efb0, tsrm_ls=0x555555ba4450)
    at zend_vm_execute.h:1640
#4  0x000055555589039b in execute (op_array=0x555555e96ad8, tsrm_ls=0x555555ba4450) at zend_vm_execute.h:92
#5  0x0000555555868a42 in zend_execute_scripts (type=8, tsrm_ls=0x555555ba4450, retval=0x0, file_count=3)
    at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/Zend/zend.c:1109
#6  0x000055555580f825 in php_execute_script (primary_file=0x7fff9f1415d0, tsrm_ls=0x555555ba4450)
    at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/main/main.c:1737
#7  0x0000555555939484 in main (argc=3, argv=0x7fff9f141888)
    at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/sapi/cli/php_cli.c:1093

Let me know if you need anything else.
 [2006-09-19 06:24 UTC]
Doesn't look like PHP problem to me.
Could you plz also see if `valgrind /usr/bin/php test.php` show you something interesting? Please put valgrind's log somewhere and paste the URL here.
 [2006-09-19 19:39 UTC] madcoder at gmail dot com
Now that's interesting...  It runs fine with valgrind.  Here are the ERROR SUMMARY and LEAK SUMMARY sections:

==7964== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 93 from 1)
==7964== malloc/free: in use at exit: 71,780 bytes in 1,268 blocks.
==7964== malloc/free: 38,082 allocs, 36,814 frees, 3,611,397 bytes allocated.
==7964== For counts of detected errors, rerun with: -v
==7964== searching for pointers to 1,268 not-freed blocks.
==7964== checked 2,962,048 bytes.

==7964== LEAK SUMMARY:
==7964==    definitely lost: 32,841 bytes in 4 blocks.
==7964==      possibly lost: 0 bytes in 0 blocks.
==7964==    still reachable: 38,939 bytes in 1,264 blocks.
==7964==         suppressed: 0 bytes in 0 blocks.
==7964== Use --leak-check=full to see details of leaked memory.

Running with --leak-check=full, I get the following:

==7968== 73 (32 direct, 41 indirect) bytes in 1 blocks are definitely lost in loss record 4 of 8
==7968==    at 0x4A1AB8E: malloc (vg_replace_malloc.c:149)
==7968==    by 0x64825AB: tds_alloc_context (in /usr/lib64/
==7968==    by 0x6472C3F: dbinit (in /usr/lib64/
==7968==    by 0x1595DC: zm_startup_mssql (php_mssql.c:301)
==7968==    by 0x31B325: zend_startup_module_ex (zend_API.c:1397)
==7968==    by 0x3224A3: zend_hash_apply (zend_hash.c:666)
==7968==    by 0x31B4EE: zend_startup_modules (zend_API.c:1444)
==7968==    by 0x2BB230: php_module_startup (main.c:1557)
==7968==    by 0x3E460A: main (php_cli.c:681)
==7968== 32,768 bytes in 1 blocks are definitely lost in loss record 8 of 8
==7968==    at 0x4A1C10D: calloc (vg_replace_malloc.c:279)
==7968==    by 0x6472C16: dbinit (in /usr/lib64/
==7968==    by 0x1595DC: zm_startup_mssql (php_mssql.c:301)
==7968==    by 0x31B325: zend_startup_module_ex (zend_API.c:1397)
==7968==    by 0x3224A3: zend_hash_apply (zend_hash.c:666)
==7968==    by 0x31B4EE: zend_startup_modules (zend_API.c:1444)
==7968==    by 0x2BB230: php_module_startup (main.c:1557)
==7968==    by 0x3E460A: main (php_cli.c:681)
 [2006-09-19 19:49 UTC] madcoder at gmail dot com
I ran it through valgrind with --leak-check=full -v --show-reachable=yes, and copied the output here:
 [2006-09-19 19:54 UTC] madcoder at gmail dot com
Apparently it looks like pastebin is having problems...  I've copied the same output here, for redundancy:
 [2006-09-23 11:32 UTC]
What was your configure line and did you enable any of mysql related extensions? If yes, then what is the version of MySQL?
 [2006-09-24 03:59 UTC] madcoder at gmail dot com
My configure line (generated by gentoo's portage):
'./configure' '--prefix=/usr/lib64/php5' '--host=x86_64-pc-linux-gnu' '--mandir=/usr/lib64/php5/man' '--infodir=/usr/lib64/php5/info' '--sysconfdir=/etc' '--cache-file=./config.cache' '--with-libdir=lib64' '--enable-cli' '--disable-cgi' '--with-apxs2=/usr/sbin/apxs2' '--enable-maintainer-zts' '--with-config-file-path=/etc/php/-php5' '--with-config-file-scan-dir=/etc/php/-php5/ext-active' '--without-pear' '--disable-bcmath' '--with-bz2' '--disable-calendar' '--disable-ctype' '--without-curl' '--without-curlwrappers' '--disable-dbase' '--disable-exif' '--without-fbsql' '--without-fdftk' '--disable-filepro' '--enable-ftp' '--with-gettext' '--without-gmp' '--disable-hash' '--without-hwapi' '--without-iconv' '--without-informix' '--disable-ipv6' '--without-kerberos' '--disable-mbstring' '--with-mcrypt' '--enable-memory-limit' '--without-mhash' '--without-ming' '--without-msql' '--with-mssql' '--with-ncurses' '--with-openssl' '--with-openssl-dir=/usr' '--disable-pcntl' '--disable-pdo' '--with-pgsql' '--disable-posix' '--with-pspell' '--without-recode' '--disable-shmop' '--with-snmp' '--enable-soap' '--enable-sockets' '--without-sybase' '--without-sybase-ct' '--disable-sysvmsg' '--disable-sysvsem' '--disable-sysvshm' '--with-tidy' '--disable-wddx' '--disable-xmlreader' '--disable-xmlwriter' '--without-xmlrpc' '--with-xsl' '--with-zlib' '--enable-debug' '--enable-dba' '--without-cdb' '--with-db4' '--without-flatfile' '--with-gdbm' '--without-inifile' '--without-qdbm' '--without-freetype-dir' '--without-t1lib' '--disable-gd-jis-conv' '--disable-gd-native-ttf' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--with-xpm-dir=/usr/X11R6' '--with-gd' '--with-ldap' '--without-ldap-sasl' '--with-mysql=/usr/lib/mysql' '--with-mysql-sock=/var/run/mysqld/mysqld.sock' '--without-mysqli' '--with-readline' '--without-libedit' '--without-mm' '--with-sqlite=/usr' '--disable-sqlite-utf8'

The version of MySQL is:
Client API version  4.1.21  

My Gentoo portage USE flags for dev-lang/php:
[ebuild   R   ] dev-lang/php-5.1.6-r4  USE="apache2 berkdb bzip2 cli crypt debug fastbuild ftp gd gdbm ldap memlimit mssql mysql ncurses nls pcre pdo-external postgres readline reflection session simplexml snmp soap sockets spell spl sqlite ssl threads tidy tokenizer xml xpm xsl zlib -apache -bcmath -calendar -cdb -cgi -cjk -concurrentmodphp -ctype -curl -curlwrappers -db2 -dbase -discard-path -doc -exif -flatfile -force-cgi-redirect -gd-external -gmp -hardenedphp -hash -hyperwave-api -iconv -imap -inifile -interbase -iodbc -ipv6 -java-external -kerberos -libedit -mcve -mhash -ming -msql -mysqli -oci8 -odbc -pcntl -pdo -pic -posix -qdbm -recode -sapdb -sasl -sharedext -sharedmem -sysvipc -truetype -unicode -vm-goto -vm-switch -wddx -xmlreader -xmlrpc -xmlwriter -yaz -zip"

I have also compiled with pdo-external, including dblib, mysql, pgsql, and sqlite support.  The pdo-mysql version is the same library (4.1.21).

I can recompile without mysql support to see if that might be part of it?  Or PDO?
 [2006-09-25 07:13 UTC]
Yes, please recompile it with just ./configure --enable-debug --with-ldap --disable-all and try again.
 [2006-09-25 21:42 UTC] madcoder at gmail dot com
I've recompiled PHP with:

# emerge -pv php
[ebuild   R   ] dev-lang/php-5.1.6-r4  USE="debug ldap -apache -apache2 -bcmath -berkdb -bzip2 -calendar -cdb -cgi -cjk -cli -concurrentmodphp -crypt -ctype -curl -curlwrappers -db2 -dbase -discard-path -doc -exif -flatfile -force-cgi-redirect -ftp -gd -gd-external -gdbm -gmp -hardenedphp -hash -hyperwave-api -iconv -imap -inifile -interbase -iodbc -ipv6 -java-external -kerberos -libedit -mcve -memlimit -mhash -ming -msql -mssql -mysql -mysqli -ncurses -nls -oci8 -odbc -pcntl -pcre -pdo -pdo-external -pic -posix -postgres -qdbm -readline -recode -reflection -sapdb -sasl -session -sharedext -sharedmem -simplexml -snmp -soap -sockets -spell -spl -sqlite -ssl -sysvipc -threads -tidy -tokenizer -truetype -unicode -vm-goto -vm-switch -wddx -xml -xmlreader -xmlrpc -xmlwriter -xpm -xsl -yaz -zip -zlib"

(enabling only ldap and debug)

It results in the following configure line, as reported by phpinfo():

Configure Command =>  './configure' '--prefix=/usr/lib64/php5' '--host=x86_64-pc-linux-gnu' '--mandir=/usr/lib64/php5/man' '--infodir=/usr/lib64/php5/info' '--sysconfdir=/etc' '--cache-file=./config.cache' '--with-libdir=lib64' '--enable-cli' '--disable-cgi' '--with-config-file-path=/etc/php/-php5' '--with-config-file-scan-dir=/etc/php/-php5/ext-active' '--without-pear' '--disable-bcmath' '--without-bz2' '--disable-calendar' '--disable-ctype' '--without-curl' '--without-curlwrappers' '--disable-dbase' '--disable-dom' '--disable-exif' '--without-fbsql' '--without-fdftk' '--disable-filepro' '--disable-ftp' '--without-gettext' '--without-gmp' '--disable-hash' '--without-hwapi' '--without-iconv' '--without-informix' '--disable-ipv6' '--without-kerberos' '--disable-libxml' '--disable-mbstring' '--without-mcrypt' '--disable-memory-limit' '--without-mhash' '--without-ming' '--without-msql' '--without-mssql' '--without-ncurses' '--without-openssl' '--without-openssl-dir' '--disable-pcntl' '--without-pcre-regex' '--disable-pdo' '--without-pgsql' '--disable-posix' '--without-pspell' '--without-recode' '--disable-reflection' '--disable-simplexml' '--disable-shmop' '--without-snmp' '--disable-soap' '--disable-sockets' '--disable-spl' '--without-sybase' '--without-sybase-ct' '--disable-sysvmsg' '--disable-sysvsem' '--disable-sysvshm' '--without-tidy' '--disable-tokenizer' '--disable-wddx' '--disable-xml' '--disable-xmlreader' '--disable-xmlwriter' '--without-xmlrpc' '--without-xsl' '--without-zlib' '--enable-debug' '--without-cdb' '--without-db4' '--without-flatfile' '--without-gdbm' '--without-inifile' '--without-qdbm' '--without-freetype-dir' '--without-t1lib' '--disable-gd-jis-conv' '--disable-gd-native-ttf' '--without-jpeg-dir' '--without-png-dir' '--without-xpm-dir' '--without-gd' '--with-ldap' '--without-ldap-sasl' '--without-mysqli' '--without-readline' '--without-libedit' '--disable-session' '--without-sqlite'

And it still segfaults:

# php -e test.php
done searching
Count: 1 entries
Segmentation fault
 [2006-09-25 21:56 UTC]
What is the backtrace and how to reproduce it?
 [2006-09-25 23:20 UTC] madcoder at gmail dot com
It's pretty much the same as before...

(gdb) bt
#0  0x00002aae16a8de44 in ldap_count_values (vals=0x559cadc0)
    at getvalues.c:153
#1  0x00005555555db423 in zif_ldap_get_entries (ht=1436331456,
    return_value=0x5555559ca5c0, return_value_ptr=0x0, this_ptr=0x0,
    at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/ext/ldap/ldap.c:1068
#2  0x00005555556e4d20 in zend_do_fcall_common_helper_SPEC (
    execute_data=0x7fff942851d0) at zend_vm_execute.h:200
#3  0x00005555556ed112 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (
    execute_data=0x7fff942851d0) at zend_vm_execute.h:1640
#4  0x00005555556e43f9 in execute (op_array=0x5555559c7ae0)
    at zend_vm_execute.h:92
#5  0x00005555556bf1d8 in zend_execute_scripts (type=8, retval=0x0,
    at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/Zend/zend.c:1109
#6  0x0000555555670784 in php_execute_script (primary_file=0x7fff94287790)
    at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/main/main.c:1737
#7  0x00005555557756f4 in main (argc=3, argv=0x7fff942879c8)
    at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/sapi/cli/php_cli.c:1093

The ldap code to reproduce the problem is the same as at the beginning of this report...  The difference between the code I posted originally and the code that gave me the above output (showing "Count: 1"), is this:

echo "done searching\n";
echo "Count: " . ldap_count_entries($_SERVER['ldap'],$r) . " entries\n";
$info = ldap_get_entries($_SERVER['ldap'], $r);

(that is, I added the Count line *after* the original post;  everything else is the same)
 [2006-09-26 07:07 UTC]
I intentionally said "how to reproduce it", not "what is the reproduce code". It's clear to me that you're still using the same code, but this code doesn't make much sense to me since I don't have your data, your variables etc.
Hence the question - how to reproduce it?
 [2006-09-26 09:29 UTC] madcoder at gmail dot com
My apologies for misunderstanding...

To reproduce the problem on my system:

1) I connect to the ldap server, which happens to be a Microsoft Active Directory domain controller, using:
  $_SERVER['ldap'] = ldap_connect("ldap://") or die("ldap connect failed");

2) Set MSAD-required options:
  ldap_set_option($_SERVER['ldap'], LDAP_OPT_PROTOCOL_VERSION, 3);
  ldap_set_option($_SERVER['ldap'], LDAP_OPT_REFERRALS, 0);

3) Bind to the LDAP directory with a search user configured with read access to the directory:
  ldap_bind($_SERVER['ldap'], '', 'some.Pass') or die('ldap bind failed');

4) Perform a basic search, looking for my User object:
  $result = ldap_search($_SERVER['ldap'], 'dc=xyz,dc=acs-inc,dc=com', '(sAMAccountName=jhansche)', array('samaccountname','telephonenumber'));

(print a couple of debug messages):
  echo "done searching\n";
  echo "Count: " . ldap_count_entries($_SERVER['ldap'],$result) . " entries\n";

5) Attempt to fetch the results of the search above:
  $info = ldap_get_entries($_SERVER['ldap'], $result);
*** This was the last line to execute before the segfault ***

(print more debugging messages):
  echo "Done fetching\n";

I then test the script with this command line (ruling out apache as any part of the problem), and receive these results to stdout/err:
  # php -e test.php
  done searching
  Count: 1 entries
  Segmentation fault
As a result of that process, running via gdb, I get the backtrace, which I have posted previously.
Running via valgrind, filtering out the valgrind output, the script *runs fine*, and produces the following output:

  # valgrind php -e test.php 2>/dev/null
  done searching
  Count: 1 entries
  Done fetching
    [Full output of the array returned by ldap_get_entries() is displayed here correctly, but snipped out for brevity's sake]
  # (end of output)

The LDAP server is running Windows Server 2003 SP1.  The segmentation fault occurs when trying to connect to either of the two domain controllers on the network.  The segfault also occurs if I leave off the LDAP_OPT_REFERRALS = 0 option, and perform a single-level search directly on the Organizational Unit containing my user account.
BASE    dc=xyz,dc=acs-inc,dc=com
URI     ldap://
TLS_CACERT /etc/ssl/certs/xyzdc02.pem
TLS_CACERTDIR /etc/ssl/certs
(note that I am not calling ldap_start_tls() in this test, so the TLS_* lines are not used)

Performing the same query via the command-line 'ldapsearch' utility from OpenLDAP:
 $ ldapsearch -H ldap:// -D -w some.Pass "(samaccountname=jhansche)" telephonenumber
  # LDAPv3
  # base <> with scope subtree
  # filter: (samaccountname=jhansche)
  # requesting: telephonenumber

  # Joe Hansche, Administrators,
  dn: CN=Joe Hansche,OU=Administrators,DC=xyz,DC=acs-inc,DC=com
  telephoneNumber: 5492

Unfortunately, I don't have another non-MS ldap server to try.  It appears that the search is completed successfully, because the ldap_count_entries() call returns 1, which is correct.  It just segfaults when trying to retrieve the actual entries with ldap_get_entries().  I hope that is more informative.  If not, please let me know what additional information I can give you that might help track this problem down.  If you'd like I can try adding some debugging messages into the ldap portion of the php source to see where it might be failing, and why?

Thanks, by the way.  I appreciate your efforts.
 [2006-09-26 09:36 UTC] madcoder at gmail dot com
Sorry for the extra post...  I just tested with different values in ldap_connect.  For all values of the hostname parameter that I tried, any that were *NOT* prefixed with "ldap://" caused a segmentation fault at line 2:
  ldap_set_option($_SERVER['ldap'], LDAP_OPT_PROTOCOL_VERSION, 3);

The various values I tried, all of which resulted in a segfault, were:
hostname (xyzdc01 and xyzdc02)
IP ( and
FQHN ( and

All of the above, when prefixed with ldap://, resulted in the same segfault described initially, at ldap_get_entries().
 [2006-09-26 09:38 UTC]
Is it possible to get an account @ this server?
 [2006-09-26 09:48 UTC] madcoder at gmail dot com
No, I'm sorry, it's on a private LAN.  A VPN account would be required to gain access to the LAN, and corporate policy won't allow me to grant you that.  If you would like to contact me off-bugzilla, I might be able to arrange a different way of accessing the server.
 [2006-09-26 10:08 UTC]
Ok, then please do the following:
1) get OpenLDAP sources from (2.3.27 is the current stable version)
2) get PHP 5.1.6 sources from
3) build openldap from the sources with --enable-debug and --prefix=/tmp/openldap
4) build PHP with ./configure --enable-debug --disable-all --with-ldap=/tmp/openldap (no need to run make install, just use CLI binary - ./sapi/cli/php).
5) try to reproduce it again and when/if it segfaults again type the following commands in gdb console:
(gdb) f 0
(gdb) p vals
(gdb) p i

I'd also appreciate if you run it through valgrind and see if there are any errors reported.
 [2006-09-26 10:28 UTC] madcoder at gmail dot com
I do still get the segfault.  This is the output from gdb:

(gdb) set args -e test.php
(gdb) run
Starting program: /root/php-5.1.6/sapi/cli/php -e test.php
done searching
Count: 1 entries

Program received signal SIGSEGV, Segmentation fault.
0x00002b92baa9a0ab in ldap_count_values (vals=0x55a07f90) at getvalues.c:153
153             for ( i = 0; vals[i] != NULL; i++ )
(gdb) f 0
#0  0x00002b92baa9a0ab in ldap_count_values (vals=0x55a07f90) at getvalues.c:153
153             for ( i = 0; vals[i] != NULL; i++ )
(gdb) p vals
$1 = (char **) 0x55a07f90
(gdb) p i
$2 = 0

If I'm understanding that correctly, it means the segfault is occuring on the first iteration of the ldap_count_values() for loop.  The first thing I notice is that 'vals' is a 32-bit pointer. Would that have any effect on the problem, considering this is a 64-bit system?  Should I have 32-bit emulation libraries installed for this?   The only reason I haven't installed the libraries so far is because none of the other packages I've installed have specifically said that they are necessary.
 [2006-09-26 10:38 UTC]
And what is in vals[0] ?
(gdb) p vals[0]
 [2006-09-26 10:43 UTC] madcoder at gmail dot com
Program received signal SIGSEGV, Segmentation fault.
0x00002af2b2e5f0ab in ldap_count_values (vals=0x55a07f90) at getvalues.c:153
153             for ( i = 0; vals[i] != NULL; i++ )
(gdb) p vals
$1 = (char **) 0x55a07f90
(gdb) p 0
$2 = 0
(gdb) p vals[0]
Cannot access memory at address 0x55a07f90

The memory address is the same.  Can't access memory?  It seems like its a problem in php's ldap_get_entries still (or further up the stack) because ldap_count_entries(), which calls the same function, works fine and returns '1'.
 [2006-09-26 10:57 UTC]
Is it possible to perform the same actions using ldapsearch utility in console?
 [2006-09-26 11:08 UTC] madcoder at gmail dot com
I've tried, but the program doesn't segfault, so it exits normally.  I'm not very experienced with gdb, so I'm not sure how to give it a breakpoint of ldap_count_values (I tried 'break ldap_count_values' and 'break ldap_count_values()', and it doesn't break).

It does still return the information as expected.
 [2006-09-30 03:37 UTC] madcoder at gmail dot com
Any other ideas?  This problem is kind of a blocker for me right now...  I still don't understand why it works fine inside valgrind, but it segfaults on its own and inside gdb.  I know it's segfaulting because of the message "Cannot access memory at address 0x55a0bfe0", so the for loop checking vals[i] obviously fails.  But what steps can I take to debug this further?

It could be a problem in openldap, since the line in php's ldap.c just before it calls the openldap function 'ldap_count_values' is ldap_get_values(), which is what is returning the memory address of 0x55a0bfe0.  But if it were in fact a problem with openldap, would the cli ldapsearch fail as well?
 [2006-10-01 08:16 UTC] madcoder at gmail dot com
For reference, I'm cross-posting a bug report I've opened with OpenLDAP (ITS# 4690) in case they can provide any further information:;expression=ldap_get_values;statetype=-1
 [2006-10-02 09:20 UTC]
So does it work for you if you add that magical -DLDAP_DEPRECATED=1 ?
 [2006-10-02 11:20 UTC] madcoder at gmail dot com
In ext/ldap/config.m4, I changed the following to add the flag you mentioned:


Then reconfigured and rebuilt php.  I'm not sure if I did that properly, but from what information I found about the flag, that is appropriate.

And I *do* still get the segfault.  Should I try a distclean as well? Or should I recompile OpenLDAP first (with or without that flag)?
 [2006-10-02 11:32 UTC] madcoder at gmail dot com
Sorry, it appears I added that in the wrong place.  I added it to the Makefile for ext/ldap, and it compiled, and works *without* any segfaults.

I don't want to sound rude, so please don't take this the wrong way, ...  But wouldn't it be beneficial to take the OpenLDAP developers' advice, and rewrite this so-called "deprecated" use of OpenLDAP?  It appears to only occur on certain machines, perhaps even only on certain amd64 machines, but it is still rather annoying if no one is sure what causes it, and it takes 2 weeks (or longer, in my case, since I've been having this problem long before I posted to any trackers) to get an answer from someone.

Thanks again for your help, and patience while working through this problem.
 [2006-10-02 11:42 UTC]
>works *without* any segfaults.
Ok, great. Please don't close the report until the issue is resolved in PHP.
Could you please also ask OpenLDAP developers if this flag would affect anything else? I.e. if it didn't segfault before, could this flag add any problems?
If no, I'll add it to the config.m4, so it'll be defined in all builds.

>But wouldn't it be beneficial to take the OpenLDAP
>developers' advice, and rewrite this so-called
>"deprecated" use of OpenLDAP?
Sure it would be. And we would gladly accept their help.
But the current situation is that ext/ldap maintainer is not active for a long time and nobody really interested in ldap. If you can help us with that - you're welcome.

Also, it would be good if OpenLDAP developers keep the backward compatibility, since we cannot rely on users using the most latest-and-greatest OpenLDAP version and rewrite ext/ldap each time they change the API.
 [2006-10-10 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2007-02-28 14:56 UTC] cardoe at gentoo dot org
Several other Gentoo users are experiencing this issue as well. The issue is still an opened one with no fixes having occurred in PHP. You can see the Gentoo bug @
 [2007-02-28 15:04 UTC]
The patch adding -DLDAP_DEPRECATED=1 has been committed 18 Oct 2006.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Jun 14 07:01:49 2024 UTC