#26409 [Bgs-Opn]: ldap_bind is causing a seg fault
ID: 26409 User updated by: pyrox_pro at hotmail dot com Reported By: pyrox_pro at hotmail dot com -Status: Bogus +Status: Open Bug Type: LDAP related Operating System: RedHat Linux 7.3 PHP Version: 4.3.4 New Comment: Just checking back. Previous Comments: [2003-12-01 12:49:37] pyrox_pro at hotmail dot com FYI I am trying to connect to Active Directory not an LDAP server, if that makes any difference or if you can test against and AD server as well. [2003-12-01 12:40:48] pyrox_pro at hotmail dot com What version of openldap are you using with that and on what OS? [2003-12-01 11:55:46] [EMAIL PROTECTED] Reopen IF openldap folks tell this isn't bug in their stuff. (FYI: I can NOT reproduce this with PHP 4.3.4 and latest Openldap) And btw. You need to always delete config.cache before reconfigure.. [2003-12-01 11:51:11] pyrox_pro at hotmail dot com I am using a conf script I have used since 4.1, that has not changed other than the addition of GD last month. Everything has worked fine with this build, up until 4.3.4 At the point of failur NOTHING had changed. Here is exactly what happened: step 1) download 4.3.4 tar gz step 2) run build script (unchanged from 4.3.2-RC build ) step 3) make install step 4) restart apache step 5) check php scripts and info.php step 6) write down SEG FAULT problems step 7) cd back to 4.3.2-RC step 8) run the same build script step 9) make install ; restart apache step 10) test ldap php script, everything works step 11) report bug to bugs.php.net step 12) ... You see, I can go back and forth between the 2 versions, and always get the same result, using the same build script, and nothing else changes at all on the system. [2003-12-01 11:42:56] [EMAIL PROTECTED] You're 100% sure NOTHING else has changed in your system? No related files have changed? (any header, library in your system?) Are you trying with fresh compile of the older PHP version? Using EXACTLY same configure line? I'm pretty sure this is openldap bug.. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/26409 -- Edit this bug report at http://bugs.php.net/?id=26409edit=1
#26409 [Bgs-Opn]: ldap_bind is causing a seg fault
ID: 26409 User updated by: pyrox_pro at hotmail dot com Reported By: pyrox_pro at hotmail dot com -Status: Bogus +Status: Open Bug Type: LDAP related Operating System: RedHat Linux 7.3 PHP Version: 4.3.4 New Comment: Is it possible that a different change effected the calls to ext/ldap function callings? I don't know. All I know is, the only variable here is the version of php, nothing else changes on the server. So from a test viewpoint, if the only variable causes a malfunction, that variable, when changed, must be the catalyst. Of course this is code, so any number of things in that version could be causing the problem. All I know is: 1) All previous versions work. 2) LDAP version did not change and is current. 3) Same result with Oracle support built in or left out. 4) Current version of ext/ldap has not changed. 5) NOTHING else has changed on the server. 6) Using 4.3.4 results in a SEG FAULT The cause? Unclear. You have suggest it is an ldap bug, so I will submit a bug to them as well. I copied the ext/ldap from 4.3.2-RC to 4.3.4 and built on those, it built, worked, and still seg faulted, so, my only thought is whatever is making the calls to the ldap functions or making use of the api is causing the seg fault. I may very well be wrong, but I am trying to track down a problem and not getting very much assistance. I will keep at this anyway. Hopefully if others are having the same issue they report it. I am using server: Apache/1.3.27 I am using: Server API Apache I am using SSL for the ldap connection: ldaps:// Could it be something to do with the SSL? Previous Comments: [2003-11-27 04:36:52] [EMAIL PROTECTED] If you don't believe me, fine, but there aren't any changes in ext/ldap between PHP 4.3.1 - 4.3.4 that could cause this crash. [2003-11-27 03:59:32] pyrox_pro at hotmail dot com Just explain one last thing then,,, Why does it work with all previous versions of php, but not this version if it is indeed in the libs and not php? If the bug was indeed in the ldap libs and not php, wouldn't it not function in previous versions? I will just go back to version 4.3.2-rc and use that. After all, THAT version of PHP works fine with this same 'supposed' bugged version of openldap. [2003-11-27 00:22:07] [EMAIL PROTECTED] It crashes inside the ldap libs - Not PHP bug. (report to openldap folks) [2003-11-26 10:53:43] pyrox_pro at hotmail dot com Here you go: Configure options: ./configure' '--prefix=/usr/local/apache' '--with-apxs=/usr/local/apache/bin/apxs' '--with-mod_charset' '--enable-force-cgi-redirect' '--enable-discard-path' '--with-config-file-path=/usr/local/apache/conf' '--enable-safe-mode' '--with-openssl' '--enable-bcmath' '--with-bz2' '--enable-calendar' '--enable-ctype' '--with-gdbm' '--enable-dbase' '--enable-ftp' '--with-gd' '--with-ttf' '--enable-gd-native-ttf' '--enable-gd-imgstrttf' '--with-jpeg-dir=/usr/local' '--enable-gd-imgstrttf' '--with-gmp' '--with-mysql' '--with-xml=shared' '--enable-shmop' '--enable-sockets' '--with-regex=php' '--enable-sysvsem' '--enable-sysvshm' '--enable-yp' '--enable-memory-limit' '--enable-shared' '--with-zlib' '--with-sybase-ct=/usr/local/freetds' '--enable-yp' '--with-xml=shared' '--with-curl' '--with-ldap' Result: [Wed Nov 26 09:43:25 2003] [notice] child pid 29410 exit signal Segmentation fault (11) Program received signal SIGSEGV, Segmentation fault. gdb backtrace: [EMAIL PROTECTED] php-4.3.4]# gdb /usr/local/apache/bin/php GNU gdb Red Hat Linux (5.2-2) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-redhat-linux... (gdb) run /usr/docroot/dev/ldap2 Starting program: /usr/local/apache/bin/php /usr/docroot/dev/ldap2 Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x400a20b4 in ldap_pvt_tls_check_hostname () from /usr/lib/libldap.so.2 #2 0x400a274f in ldap_int_tls_start () from /usr/lib/libldap.so.2 #3 0x40088ff1 in ldap_int_open_connection () from /usr/lib/libldap.so.2 #4 0x40097593 in ldap_new_connection () from /usr/lib/libldap.so.2 #5 0x40088a9a in ldap_open_defconn () from /usr/lib/libldap.so.2 #6 0x4009722f in ldap_send_initial_request () from /usr/lib/libldap.so.2 #7 0x40090be1 in ldap_sasl_bind () from /usr/lib/libldap.so.2 #8 0x40090c9a in ldap_sasl_bind_s () from /usr/lib/libldap.so.2 #9
#26409 [Bgs-Opn]: ldap_bind is causing a seg fault
ID: 26409 User updated by: pyrox_pro at hotmail dot com Reported By: pyrox_pro at hotmail dot com -Status: Bogus +Status: Open Bug Type: LDAP related Operating System: RedHat Linux 7.3 PHP Version: 4.3.4 New Comment: I am using a conf script I have used since 4.1, that has not changed other than the addition of GD last month. Everything has worked fine with this build, up until 4.3.4 At the point of failur NOTHING had changed. Here is exactly what happened: step 1) download 4.3.4 tar gz step 2) run build script (unchanged from 4.3.2-RC build ) step 3) make install step 4) restart apache step 5) check php scripts and info.php step 6) write down SEG FAULT problems step 7) cd back to 4.3.2-RC step 8) run the same build script step 9) make install ; restart apache step 10) test ldap php script, everything works step 11) report bug to bugs.php.net step 12) ... You see, I can go back and forth between the 2 versions, and always get the same result, using the same build script, and nothing else changes at all on the system. Previous Comments: [2003-12-01 11:42:56] [EMAIL PROTECTED] You're 100% sure NOTHING else has changed in your system? No related files have changed? (any header, library in your system?) Are you trying with fresh compile of the older PHP version? Using EXACTLY same configure line? I'm pretty sure this is openldap bug.. [2003-12-01 11:30:05] pyrox_pro at hotmail dot com Is it possible that a different change effected the calls to ext/ldap function callings? I don't know. All I know is, the only variable here is the version of php, nothing else changes on the server. So from a test viewpoint, if the only variable causes a malfunction, that variable, when changed, must be the catalyst. Of course this is code, so any number of things in that version could be causing the problem. All I know is: 1) All previous versions work. 2) LDAP version did not change and is current. 3) Same result with Oracle support built in or left out. 4) Current version of ext/ldap has not changed. 5) NOTHING else has changed on the server. 6) Using 4.3.4 results in a SEG FAULT The cause? Unclear. You have suggest it is an ldap bug, so I will submit a bug to them as well. I copied the ext/ldap from 4.3.2-RC to 4.3.4 and built on those, it built, worked, and still seg faulted, so, my only thought is whatever is making the calls to the ldap functions or making use of the api is causing the seg fault. I may very well be wrong, but I am trying to track down a problem and not getting very much assistance. I will keep at this anyway. Hopefully if others are having the same issue they report it. I am using server: Apache/1.3.27 I am using: Server API Apache I am using SSL for the ldap connection: ldaps:// Could it be something to do with the SSL? [2003-11-27 04:36:52] [EMAIL PROTECTED] If you don't believe me, fine, but there aren't any changes in ext/ldap between PHP 4.3.1 - 4.3.4 that could cause this crash. [2003-11-27 03:59:32] pyrox_pro at hotmail dot com Just explain one last thing then,,, Why does it work with all previous versions of php, but not this version if it is indeed in the libs and not php? If the bug was indeed in the ldap libs and not php, wouldn't it not function in previous versions? I will just go back to version 4.3.2-rc and use that. After all, THAT version of PHP works fine with this same 'supposed' bugged version of openldap. [2003-11-27 00:22:07] [EMAIL PROTECTED] It crashes inside the ldap libs - Not PHP bug. (report to openldap folks) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/26409 -- Edit this bug report at http://bugs.php.net/?id=26409edit=1
#26409 [Bgs]: ldap_bind is causing a seg fault
ID: 26409 User updated by: pyrox_pro at hotmail dot com Reported By: pyrox_pro at hotmail dot com Status: Bogus Bug Type: LDAP related Operating System: RedHat Linux 7.3 PHP Version: 4.3.4 New Comment: What version of openldap are you using with that and on what OS? Previous Comments: [2003-12-01 11:55:46] [EMAIL PROTECTED] Reopen IF openldap folks tell this isn't bug in their stuff. (FYI: I can NOT reproduce this with PHP 4.3.4 and latest Openldap) And btw. You need to always delete config.cache before reconfigure.. [2003-12-01 11:51:11] pyrox_pro at hotmail dot com I am using a conf script I have used since 4.1, that has not changed other than the addition of GD last month. Everything has worked fine with this build, up until 4.3.4 At the point of failur NOTHING had changed. Here is exactly what happened: step 1) download 4.3.4 tar gz step 2) run build script (unchanged from 4.3.2-RC build ) step 3) make install step 4) restart apache step 5) check php scripts and info.php step 6) write down SEG FAULT problems step 7) cd back to 4.3.2-RC step 8) run the same build script step 9) make install ; restart apache step 10) test ldap php script, everything works step 11) report bug to bugs.php.net step 12) ... You see, I can go back and forth between the 2 versions, and always get the same result, using the same build script, and nothing else changes at all on the system. [2003-12-01 11:42:56] [EMAIL PROTECTED] You're 100% sure NOTHING else has changed in your system? No related files have changed? (any header, library in your system?) Are you trying with fresh compile of the older PHP version? Using EXACTLY same configure line? I'm pretty sure this is openldap bug.. [2003-12-01 11:30:05] pyrox_pro at hotmail dot com Is it possible that a different change effected the calls to ext/ldap function callings? I don't know. All I know is, the only variable here is the version of php, nothing else changes on the server. So from a test viewpoint, if the only variable causes a malfunction, that variable, when changed, must be the catalyst. Of course this is code, so any number of things in that version could be causing the problem. All I know is: 1) All previous versions work. 2) LDAP version did not change and is current. 3) Same result with Oracle support built in or left out. 4) Current version of ext/ldap has not changed. 5) NOTHING else has changed on the server. 6) Using 4.3.4 results in a SEG FAULT The cause? Unclear. You have suggest it is an ldap bug, so I will submit a bug to them as well. I copied the ext/ldap from 4.3.2-RC to 4.3.4 and built on those, it built, worked, and still seg faulted, so, my only thought is whatever is making the calls to the ldap functions or making use of the api is causing the seg fault. I may very well be wrong, but I am trying to track down a problem and not getting very much assistance. I will keep at this anyway. Hopefully if others are having the same issue they report it. I am using server: Apache/1.3.27 I am using: Server API Apache I am using SSL for the ldap connection: ldaps:// Could it be something to do with the SSL? [2003-11-27 04:36:52] [EMAIL PROTECTED] If you don't believe me, fine, but there aren't any changes in ext/ldap between PHP 4.3.1 - 4.3.4 that could cause this crash. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/26409 -- Edit this bug report at http://bugs.php.net/?id=26409edit=1
#26409 [Bgs]: ldap_bind is causing a seg fault
ID: 26409 User updated by: pyrox_pro at hotmail dot com Reported By: pyrox_pro at hotmail dot com Status: Bogus Bug Type: LDAP related Operating System: RedHat Linux 7.3 PHP Version: 4.3.4 New Comment: FYI I am trying to connect to Active Directory not an LDAP server, if that makes any difference or if you can test against and AD server as well. Previous Comments: [2003-12-01 12:40:48] pyrox_pro at hotmail dot com What version of openldap are you using with that and on what OS? [2003-12-01 11:55:46] [EMAIL PROTECTED] Reopen IF openldap folks tell this isn't bug in their stuff. (FYI: I can NOT reproduce this with PHP 4.3.4 and latest Openldap) And btw. You need to always delete config.cache before reconfigure.. [2003-12-01 11:51:11] pyrox_pro at hotmail dot com I am using a conf script I have used since 4.1, that has not changed other than the addition of GD last month. Everything has worked fine with this build, up until 4.3.4 At the point of failur NOTHING had changed. Here is exactly what happened: step 1) download 4.3.4 tar gz step 2) run build script (unchanged from 4.3.2-RC build ) step 3) make install step 4) restart apache step 5) check php scripts and info.php step 6) write down SEG FAULT problems step 7) cd back to 4.3.2-RC step 8) run the same build script step 9) make install ; restart apache step 10) test ldap php script, everything works step 11) report bug to bugs.php.net step 12) ... You see, I can go back and forth between the 2 versions, and always get the same result, using the same build script, and nothing else changes at all on the system. [2003-12-01 11:42:56] [EMAIL PROTECTED] You're 100% sure NOTHING else has changed in your system? No related files have changed? (any header, library in your system?) Are you trying with fresh compile of the older PHP version? Using EXACTLY same configure line? I'm pretty sure this is openldap bug.. [2003-12-01 11:30:05] pyrox_pro at hotmail dot com Is it possible that a different change effected the calls to ext/ldap function callings? I don't know. All I know is, the only variable here is the version of php, nothing else changes on the server. So from a test viewpoint, if the only variable causes a malfunction, that variable, when changed, must be the catalyst. Of course this is code, so any number of things in that version could be causing the problem. All I know is: 1) All previous versions work. 2) LDAP version did not change and is current. 3) Same result with Oracle support built in or left out. 4) Current version of ext/ldap has not changed. 5) NOTHING else has changed on the server. 6) Using 4.3.4 results in a SEG FAULT The cause? Unclear. You have suggest it is an ldap bug, so I will submit a bug to them as well. I copied the ext/ldap from 4.3.2-RC to 4.3.4 and built on those, it built, worked, and still seg faulted, so, my only thought is whatever is making the calls to the ldap functions or making use of the api is causing the seg fault. I may very well be wrong, but I am trying to track down a problem and not getting very much assistance. I will keep at this anyway. Hopefully if others are having the same issue they report it. I am using server: Apache/1.3.27 I am using: Server API Apache I am using SSL for the ldap connection: ldaps:// Could it be something to do with the SSL? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/26409 -- Edit this bug report at http://bugs.php.net/?id=26409edit=1
#26409 [Bgs-Opn]: ldap_bind is causing a seg fault
ID: 26409 User updated by: pyrox_pro at hotmail dot com Reported By: pyrox_pro at hotmail dot com -Status: Bogus +Status: Open Bug Type: LDAP related Operating System: RedHat Linux 7.3 PHP Version: 4.3.4 New Comment: Just explain one last thing then,,, Why does it work with all previous versions of php, but not this version if it is indeed in the libs and not php? If the bug was indeed in the ldap libs and not php, wouldn't it not function in previous versions? I will just go back to version 4.3.2-rc and use that. After all, THAT version of PHP works fine with this same 'supposed' bugged version of openldap. Previous Comments: [2003-11-27 00:22:07] [EMAIL PROTECTED] It crashes inside the ldap libs - Not PHP bug. (report to openldap folks) [2003-11-26 10:53:43] pyrox_pro at hotmail dot com Here you go: Configure options: ./configure' '--prefix=/usr/local/apache' '--with-apxs=/usr/local/apache/bin/apxs' '--with-mod_charset' '--enable-force-cgi-redirect' '--enable-discard-path' '--with-config-file-path=/usr/local/apache/conf' '--enable-safe-mode' '--with-openssl' '--enable-bcmath' '--with-bz2' '--enable-calendar' '--enable-ctype' '--with-gdbm' '--enable-dbase' '--enable-ftp' '--with-gd' '--with-ttf' '--enable-gd-native-ttf' '--enable-gd-imgstrttf' '--with-jpeg-dir=/usr/local' '--enable-gd-imgstrttf' '--with-gmp' '--with-mysql' '--with-xml=shared' '--enable-shmop' '--enable-sockets' '--with-regex=php' '--enable-sysvsem' '--enable-sysvshm' '--enable-yp' '--enable-memory-limit' '--enable-shared' '--with-zlib' '--with-sybase-ct=/usr/local/freetds' '--enable-yp' '--with-xml=shared' '--with-curl' '--with-ldap' Result: [Wed Nov 26 09:43:25 2003] [notice] child pid 29410 exit signal Segmentation fault (11) Program received signal SIGSEGV, Segmentation fault. gdb backtrace: [EMAIL PROTECTED] php-4.3.4]# gdb /usr/local/apache/bin/php GNU gdb Red Hat Linux (5.2-2) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-redhat-linux... (gdb) run /usr/docroot/dev/ldap2 Starting program: /usr/local/apache/bin/php /usr/docroot/dev/ldap2 Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x400a20b4 in ldap_pvt_tls_check_hostname () from /usr/lib/libldap.so.2 #2 0x400a274f in ldap_int_tls_start () from /usr/lib/libldap.so.2 #3 0x40088ff1 in ldap_int_open_connection () from /usr/lib/libldap.so.2 #4 0x40097593 in ldap_new_connection () from /usr/lib/libldap.so.2 #5 0x40088a9a in ldap_open_defconn () from /usr/lib/libldap.so.2 #6 0x4009722f in ldap_send_initial_request () from /usr/lib/libldap.so.2 #7 0x40090be1 in ldap_sasl_bind () from /usr/lib/libldap.so.2 #8 0x40090c9a in ldap_sasl_bind_s () from /usr/lib/libldap.so.2 #9 0x4009138c in ldap_simple_bind_s () from /usr/lib/libldap.so.2 #10 0x40088a49 in ldap_bind_s () from /usr/lib/libldap.so.2 #11 0x080c62a2 in zif_ldap_bind (ht=3, return_value=0x8348ac4, this_ptr=0x0, return_value_used=1) at /root/php-4.3.4/ext/ldap/ldap.c:460 #12 0x081aa480 in execute (op_array=0x8339924) at /root/php-4.3.4/Zend/zend_execute.c:1616 #13 0x08197ecc in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /root/php-4.3.4/Zend/zend.c:884 #14 0x08170a14 in php_execute_script (primary_file=0xbaa0) at /root/php-4.3.4/main/main.c:1729 #15 0x081b2984 in main (argc=2, argv=0xbb44) at /root/php-4.3.4/sapi/cli/php_cli.c:819 #16 0x401da1c4 in __libc_start_main () from /lib/libc.so.6 (gdb) frame 12 #12 0x081aa480 in execute (op_array=0x8339924) at /root/php-4.3.4/Zend/zend_execute.c:1616 1616 ((zend_internal_function *) EX(function_state).function)-handler(EX(opline)-extended_value, EX(Ts)[EX(opline)-result.u.var].var.ptr, EX(object).ptr, return_value_used TSRMLS_CC); (gdb) print (char A parse error in expression, near `'. (gdb) print (char*)(executor_globals.function_state_ptr-function)-common.function_name $1 = 0x823857c ldap_bind (gdb) RESULT: $1 = 0x823857c ldap_bind No Oracle support in this buildp, up to date ldap libs. Same Result. [2003-11-25 19:38:48] [EMAIL PROTECTED] Try compile PHP without --with-oci8 altogether. And use the openldap libs intstead for --with-ldap so we know for sure this really is caused by oracle.. [2003-11-25 12:15:25] pyrox_pro at hotmail dot com Description
#26409 [Fbk-Opn]: ldap_bind is causing a seg fault
ID: 26409 User updated by: pyrox_pro at hotmail dot com Reported By: pyrox_pro at hotmail dot com -Status: Feedback +Status: Open Bug Type: LDAP related Operating System: RedHat Linux 7.3 PHP Version: 4.3.4 New Comment: Here you go: Configure options: ./configure' '--prefix=/usr/local/apache' '--with-apxs=/usr/local/apache/bin/apxs' '--with-mod_charset' '--enable-force-cgi-redirect' '--enable-discard-path' '--with-config-file-path=/usr/local/apache/conf' '--enable-safe-mode' '--with-openssl' '--enable-bcmath' '--with-bz2' '--enable-calendar' '--enable-ctype' '--with-gdbm' '--enable-dbase' '--enable-ftp' '--with-gd' '--with-ttf' '--enable-gd-native-ttf' '--enable-gd-imgstrttf' '--with-jpeg-dir=/usr/local' '--enable-gd-imgstrttf' '--with-gmp' '--with-mysql' '--with-xml=shared' '--enable-shmop' '--enable-sockets' '--with-regex=php' '--enable-sysvsem' '--enable-sysvshm' '--enable-yp' '--enable-memory-limit' '--enable-shared' '--with-zlib' '--with-sybase-ct=/usr/local/freetds' '--enable-yp' '--with-xml=shared' '--with-curl' '--with-ldap' Result: [Wed Nov 26 09:43:25 2003] [notice] child pid 29410 exit signal Segmentation fault (11) Program received signal SIGSEGV, Segmentation fault. gdb backtrace: [EMAIL PROTECTED] php-4.3.4]# gdb /usr/local/apache/bin/php GNU gdb Red Hat Linux (5.2-2) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-redhat-linux... (gdb) run /usr/docroot/dev/ldap2 Starting program: /usr/local/apache/bin/php /usr/docroot/dev/ldap2 Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x400a20b4 in ldap_pvt_tls_check_hostname () from /usr/lib/libldap.so.2 #2 0x400a274f in ldap_int_tls_start () from /usr/lib/libldap.so.2 #3 0x40088ff1 in ldap_int_open_connection () from /usr/lib/libldap.so.2 #4 0x40097593 in ldap_new_connection () from /usr/lib/libldap.so.2 #5 0x40088a9a in ldap_open_defconn () from /usr/lib/libldap.so.2 #6 0x4009722f in ldap_send_initial_request () from /usr/lib/libldap.so.2 #7 0x40090be1 in ldap_sasl_bind () from /usr/lib/libldap.so.2 #8 0x40090c9a in ldap_sasl_bind_s () from /usr/lib/libldap.so.2 #9 0x4009138c in ldap_simple_bind_s () from /usr/lib/libldap.so.2 #10 0x40088a49 in ldap_bind_s () from /usr/lib/libldap.so.2 #11 0x080c62a2 in zif_ldap_bind (ht=3, return_value=0x8348ac4, this_ptr=0x0, return_value_used=1) at /root/php-4.3.4/ext/ldap/ldap.c:460 #12 0x081aa480 in execute (op_array=0x8339924) at /root/php-4.3.4/Zend/zend_execute.c:1616 #13 0x08197ecc in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /root/php-4.3.4/Zend/zend.c:884 #14 0x08170a14 in php_execute_script (primary_file=0xbaa0) at /root/php-4.3.4/main/main.c:1729 #15 0x081b2984 in main (argc=2, argv=0xbb44) at /root/php-4.3.4/sapi/cli/php_cli.c:819 #16 0x401da1c4 in __libc_start_main () from /lib/libc.so.6 (gdb) frame 12 #12 0x081aa480 in execute (op_array=0x8339924) at /root/php-4.3.4/Zend/zend_execute.c:1616 1616 ((zend_internal_function *) EX(function_state).function)-handler(EX(opline)-extended_value, EX(Ts)[EX(opline)-result.u.var].var.ptr, EX(object).ptr, return_value_used TSRMLS_CC); (gdb) print (char A parse error in expression, near `'. (gdb) print (char*)(executor_globals.function_state_ptr-function)-common.function_name $1 = 0x823857c ldap_bind (gdb) RESULT: $1 = 0x823857c ldap_bind No Oracle support in this buildp, up to date ldap libs. Same Result. Previous Comments: [2003-11-25 19:38:48] [EMAIL PROTECTED] Try compile PHP without --with-oci8 altogether. And use the openldap libs intstead for --with-ldap so we know for sure this really is caused by oracle.. [2003-11-25 16:52:21] pyrox_pro at hotmail dot com I did as requested, added my Oracle libs and built php with the configure line pointing ldap to them. Now I am getting: Warning: ldap_error(): supplied argument is not a valid ldap link resource in /usr/docroot/dev/ldap.php on line 14 Warning: ldap_bind() expects parameter 1 to be resource, boolean given in /usr/docroot/dev/ldap.php on line 15 $ds=ldap_connect(ldaps://myhostnameishere/); echo ldap_error($ds); $r=ldap_bind($ds,$ldap['user'],$ldap['pass']); Still not functional. This kind of problem defies logic. Should it not return either: A) A link ref B) False ?? The code in the manual is not function now either. [2003-11-25 15:48:49] pyrox_pro
#19434 [Com]: oci8 + ldap - crash
ID: 19434
Comment by: pyrox_pro at hotmail dot com
Reported By: ronan dot salmon at staff dot ittralee dot ie
Status: No Feedback
Bug Type: OCI8 related
Operating System: redhat 7.3
PHP Version: 4.3.3RC4-dev
New Comment:
Similar issue, mine happens on Bind.
echo BRConnecting...;
$ds=ldap_connect(ldaps://.$ldap['SERV']./) or die(BRDied.);
echo BR Connection Established: $ds;
echo BR BINDING...;
$r=ldap_bind($ds,$ldap['user'],$ldap['pass']);
echo BR BIND COMPLETE.;
This results in a page cannot be found.
If I comment this out:
echo BRConnecting...;
$ds=ldap_connect(ldaps://.$ldap['SERV']./) or die(BRDied.);
echo BR Connection Established: $ds;
echo BR BINDING...;
##$r=ldap_bind($ds,$ldap['user'],$ldap['pass']);
echo BR BIND COMPLETE.;
The page comes up and it seems to work fine.
I have let the thing spin forever with no response.
I am using php 4.3.4 and LDAP:
ldap
LDAP Support enabled
RCS Version $Id: ldap.c,v 1.130.2.9 2003/10/07 00:36:27 iliaa Exp $
Total Links 0/unlimited
API Version 2004
Vendor Name OpenLDAP
Vendor Version 20026
OCI8 Support enabled
Revision $Revision: 1.183.2.5 $
Oracle Version 8.1
Compile-time ORACLE_HOME /u01/app/oracle/product/8.1.6
Libraries Used no value
OpenSSL support enabled
OpenSSL Version OpenSSL 0.9.7 31 Dec 2002
Previous Comments:
[2003-10-19 10:24:25] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to Open. Thank you.
[2003-10-14 21:02:49] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2003-07-17 03:40:47] ronan dot salmon at staff dot ittralee dot ie
Sorry, I don't know what I've done yesterday but in fact LDAP doesn't
work alone anymore.
Here the script :
?php
include('config.php');
$connLDAP = ldap_connect('10.10.1.19');
if (!$connLDAP)
{
echo 'Failed to connect to 10.10.1.19';
exit;
}
// Lookup user
@ldap_bind($connLDAP);
$ldapsearch = ldap_search($connLDAP,
'ou=people,ou=staff,dc=ittralee,dc=ie', uid=$strLogin);
$arrInfo = ldap_get_entries($connLDAP, $ldapsearch);
$boolLogin = @ldap_bind($connLDAP, $strDN, $strPasswd);
if (!$boolLogin)
{
echo BRWrong username or password!P\n;
exit;
}
?
I'm using the same php as yesterday.
[~/php]# gdb ./php4-STABLE-200307160330/sapi/cgi/php login.php
(gdb) run login.php
Starting program: /root/php/php4-STABLE-200307160330/sapi/cgi/php
login.php
[New Thread 16384 (LWP 23469)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 23469)]
0x40a71a34 in _int_free () from /lib/libc.so.6
(gdb) bt
#0 0x40a71a34 in _int_free () from /lib/libc.so.6
#1 0x40a709cc in free () from /lib/libc.so.6
#2 0x08065d81 in zif_ldap_get_entries (ht=2, return_value=0x8208040,
this_ptr=0x0, return_value_used=1, tsrm_ls=0x40d76440)
at /root/php/php4-STABLE-200307160330/ext/ldap/ldap.c:953
#3 0x0813ce45 in execute (op_array=0x8203028, tsrm_ls=0x81876b0)
at /root/php/php4-STABLE-200307160330/Zend/zend_execute.c:1616
#4 0x0812f7f1 in zend_execute_scripts (type=8, tsrm_ls=0x81876b0,
retval=0x0,
file_count=3) at
/root/php/php4-STABLE-200307160330/Zend/zend.c:886
#5 0x08106305 in php_execute_script (primary_file=0xb980,
tsrm_ls=0x81876b0) at
/root/php/php4-STABLE-200307160330/main/main.c:1685
#6 0x08142609 in main (argc=2, argv=0xba14)
at /root/php/php4-STABLE-200307160330/sapi/cgi/cgi_main.c:1542
#7 0x40a195cd in __libc_start_main () from /lib/libc.so.6
[2003-07-16 14:31:31] [EMAIL PROTECTED]
Can you try and reduce your script to smallest possible that causes the
crash? (like with only the ldap stuff?)
[2002-09-26 20:22:44] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
Reduce your configure options to bare minimum,
only use --with-apxs, --with-oci8 and --with-ldap and
don't compile them as shared!
Do this using the latest snapshot above.
The remainder of the comments
#19434 [Com]: oci8 + ldap - crash
ID: 19434
Comment by: pyrox_pro at hotmail dot com
Reported By: ronan dot salmon at staff dot ittralee dot ie
Status: No Feedback
Bug Type: OCI8 related
Operating System: redhat 7.3
PHP Version: 4.3.3RC4-dev
New Comment:
I have just confirmed that it is:
[Tue Nov 25 10:15:44 2003] [notice] child pid 25048 exit signal
Segmentation fault (11)
The ldap_bind is causing a seg fault.
Previous Comments:
[2003-11-25 11:29:36] pyrox_pro at hotmail dot com
Similar issue, mine happens on Bind.
echo BRConnecting...;
$ds=ldap_connect(ldaps://.$ldap['SERV']./) or die(BRDied.);
echo BR Connection Established: $ds;
echo BR BINDING...;
$r=ldap_bind($ds,$ldap['user'],$ldap['pass']);
echo BR BIND COMPLETE.;
This results in a page cannot be found.
If I comment this out:
echo BRConnecting...;
$ds=ldap_connect(ldaps://.$ldap['SERV']./) or die(BRDied.);
echo BR Connection Established: $ds;
echo BR BINDING...;
##$r=ldap_bind($ds,$ldap['user'],$ldap['pass']);
echo BR BIND COMPLETE.;
The page comes up and it seems to work fine.
I have let the thing spin forever with no response.
I am using php 4.3.4 and LDAP:
ldap
LDAP Support enabled
RCS Version $Id: ldap.c,v 1.130.2.9 2003/10/07 00:36:27 iliaa Exp $
Total Links 0/unlimited
API Version 2004
Vendor Name OpenLDAP
Vendor Version 20026
OCI8 Support enabled
Revision $Revision: 1.183.2.5 $
Oracle Version 8.1
Compile-time ORACLE_HOME /u01/app/oracle/product/8.1.6
Libraries Used no value
OpenSSL support enabled
OpenSSL Version OpenSSL 0.9.7 31 Dec 2002
[2003-10-19 10:24:25] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to Open. Thank you.
[2003-10-14 21:02:49] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2003-07-17 03:40:47] ronan dot salmon at staff dot ittralee dot ie
Sorry, I don't know what I've done yesterday but in fact LDAP doesn't
work alone anymore.
Here the script :
?php
include('config.php');
$connLDAP = ldap_connect('10.10.1.19');
if (!$connLDAP)
{
echo 'Failed to connect to 10.10.1.19';
exit;
}
// Lookup user
@ldap_bind($connLDAP);
$ldapsearch = ldap_search($connLDAP,
'ou=people,ou=staff,dc=ittralee,dc=ie', uid=$strLogin);
$arrInfo = ldap_get_entries($connLDAP, $ldapsearch);
$boolLogin = @ldap_bind($connLDAP, $strDN, $strPasswd);
if (!$boolLogin)
{
echo BRWrong username or password!P\n;
exit;
}
?
I'm using the same php as yesterday.
[~/php]# gdb ./php4-STABLE-200307160330/sapi/cgi/php login.php
(gdb) run login.php
Starting program: /root/php/php4-STABLE-200307160330/sapi/cgi/php
login.php
[New Thread 16384 (LWP 23469)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 23469)]
0x40a71a34 in _int_free () from /lib/libc.so.6
(gdb) bt
#0 0x40a71a34 in _int_free () from /lib/libc.so.6
#1 0x40a709cc in free () from /lib/libc.so.6
#2 0x08065d81 in zif_ldap_get_entries (ht=2, return_value=0x8208040,
this_ptr=0x0, return_value_used=1, tsrm_ls=0x40d76440)
at /root/php/php4-STABLE-200307160330/ext/ldap/ldap.c:953
#3 0x0813ce45 in execute (op_array=0x8203028, tsrm_ls=0x81876b0)
at /root/php/php4-STABLE-200307160330/Zend/zend_execute.c:1616
#4 0x0812f7f1 in zend_execute_scripts (type=8, tsrm_ls=0x81876b0,
retval=0x0,
file_count=3) at
/root/php/php4-STABLE-200307160330/Zend/zend.c:886
#5 0x08106305 in php_execute_script (primary_file=0xb980,
tsrm_ls=0x81876b0) at
/root/php/php4-STABLE-200307160330/main/main.c:1685
#6 0x08142609 in main (argc=2, argv=0xba14)
at /root/php/php4-STABLE-200307160330/sapi/cgi/cgi_main.c:1542
#7 0x40a195cd in __libc_start_main () from /lib/libc.so.6
[2003-07-16 14:31:31] [EMAIL PROTECTED]
Can you try and reduce your script to smallest possible that causes the
crash? (like with only the ldap stuff?)
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/19434
--
Edit this bug report
#26409 [NEW]: ldap_bind is causing a seg fault
From: pyrox_pro at hotmail dot com Operating system: RedHat Linux 7.3 PHP version: 4.3.4 PHP Bug Type: LDAP related Bug description: ldap_bind is causing a seg fault Description: ldap_bind is causing a seg fault on every use. I submitted a similar bug in the past and was supplied a CVS snapshot to use, I had been using that up until now, I installed php-4.3.4 and a new problem that is similar rears its head: http://bugs.php.net/bug.php?id=22686 echo BRConnecting...; $ds=ldap_connect(ldaps://.$ldap['SERV']./) or die(BRDied.); echo BR Connection Established: $ds; echo BR BINDING...; $r=ldap_bind($ds,$ldap['user'],$ldap['pass']); echo BR BIND COMPLETE.; This results in a seg fault: Connecting... Connection Established: Resource id #4 BINDING... ** - Segmentation fault [Tue Nov 25 10:31:38 2003] [notice] child pid 26178 exit signal Segmentation fault (11) If I comment this out: echo BRConnecting...; $ds=ldap_connect(ldaps://.$ldap['SERV']./) or die(BRDied.); echo BR Connection Established: $ds; echo BR BINDING...; ##$r=ldap_bind($ds,$ldap['user'],$ldap['pass']); echo BR BIND COMPLETE.; The page comes up and it seems to work fine. I am using php 4.3.4 and LDAP: ldap LDAP Support enabled RCS Version $Id: ldap.c,v 1.130.2.9 2003/10/07 00:36:27 iliaa Exp $ Total Links 0/unlimited API Version 2004 Vendor Name OpenLDAP Vendor Version 20026 OCI8 Support enabled Revision $Revision: 1.183.2.5 $ Oracle Version 8.1 Compile-time ORACLE_HOME /u01/app/oracle/product/8.1.6 Libraries Used no value OpenSSL support enabled OpenSSL Version OpenSSL 0.9.7 31 Dec 2002 Reproduce code: --- $ds=ldap_connect(ldaps://.$ldap['SERV']./); $r=ldap_bind($ds); Expected result: Annon bind to the ldap resource id obtained from ldap_connect. Actual result: -- Segmentation fault -- Edit bug report at http://bugs.php.net/?id=26409edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26409r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26409r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26409r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26409r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26409r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26409r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26409r=support Expected behavior: http://bugs.php.net/fix.php?id=26409r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26409r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26409r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26409r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26409r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26409r=dst IIS Stability: http://bugs.php.net/fix.php?id=26409r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26409r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26409r=float
#26409 [Fbk-Opn]: ldap_bind is causing a seg fault
ID: 26409 User updated by: pyrox_pro at hotmail dot com Reported By: pyrox_pro at hotmail dot com -Status: Feedback +Status: Open Bug Type: LDAP related Operating System: RedHat Linux 7.3 PHP Version: 4.3.4 New Comment: If I must submit a backtrace it will be next week before I can get to that, this is important to me so I def. want to help. I got the code running again by going back to verion PHP Version 4.3.2-RC (php4-STABLE-200303141430) and manually updating PEAR. Here is my configure: ./configure' '--with-oci8' '--prefix=/usr/local/apache' '--with-apxs=/usr/local/apache/bin/apxs' '--with-mod_charset' '--enable-force-cgi-redirect' '--enable-discard-path' '--with-config-file-path=/usr/local/apache/conf' '--enable-safe-mode' '--with-openssl' '--enable-bcmath' '--with-bz2' '--enable-calendar' '--enable-ctype' '--with-gdbm' '--enable-dbase' '--enable-ftp' '--with-gd' '--with-ttf' '--enable-gd-native-ttf' '--enable-gd-imgstrttf' '--with-jpeg-dir=/usr/local' '--enable-gd-imgstrttf' '--with-gmp' '--with-mysql' '--with-xml=shared' '--enable-shmop' '--enable-sockets' '--with-regex=php' '--enable-sysvsem' '--enable-sysvshm' '--enable-yp' '--enable-memory-limit' '--enable-shared' '--with-zlib' '--with-sybase-ct=/usr/local/freetds' '--with-ldap' '--enable-yp' '--with-xml=shared' '--with-curl' Is there any other method of getting you the info you need, for example: bash# strace /path/to/php /path/to/script.php Thanks for looking into this. Previous Comments: [2003-11-25 14:26:13] [EMAIL PROTECTED] 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 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. And also the full configure line would be good to know.. [2003-11-25 12:15:25] pyrox_pro at hotmail dot com Description: ldap_bind is causing a seg fault on every use. I submitted a similar bug in the past and was supplied a CVS snapshot to use, I had been using that up until now, I installed php-4.3.4 and a new problem that is similar rears its head: http://bugs.php.net/bug.php?id=22686 echo BRConnecting...; $ds=ldap_connect(ldaps://.$ldap['SERV']./) or die(BRDied.); echo BR Connection Established: $ds; echo BR BINDING...; $r=ldap_bind($ds,$ldap['user'],$ldap['pass']); echo BR BIND COMPLETE.; This results in a seg fault: Connecting... Connection Established: Resource id #4 BINDING... ** - Segmentation fault [Tue Nov 25 10:31:38 2003] [notice] child pid 26178 exit signal Segmentation fault (11) If I comment this out: echo BRConnecting...; $ds=ldap_connect(ldaps://.$ldap['SERV']./) or die(BRDied.); echo BR Connection Established: $ds; echo BR BINDING...; ##$r=ldap_bind($ds,$ldap['user'],$ldap['pass']); echo BR BIND COMPLETE.; The page comes up and it seems to work fine. I am using php 4.3.4 and LDAP: ldap LDAP Support enabled RCS Version $Id: ldap.c,v 1.130.2.9 2003/10/07 00:36:27 iliaa Exp $ Total Links 0/unlimited API Version 2004 Vendor Name OpenLDAP Vendor Version 20026 OCI8 Support enabled Revision $Revision: 1.183.2.5 $ Oracle Version 8.1 Compile-time ORACLE_HOME /u01/app/oracle/product/8.1.6 Libraries Used no value OpenSSL support enabled OpenSSL Version OpenSSL 0.9.7 31 Dec 2002 Reproduce code: --- $ds=ldap_connect(ldaps://.$ldap['SERV']./); $r=ldap_bind($ds); Expected result: Annon bind to the ldap resource id obtained from ldap_connect. Actual result: -- Segmentation fault -- Edit this bug report at http://bugs.php.net/?id=26409edit=1
#26409 [Bgs-Opn]: ldap_bind is causing a seg fault
ID: 26409 User updated by: pyrox_pro at hotmail dot com Reported By: pyrox_pro at hotmail dot com -Status: Bogus +Status: Open Bug Type: LDAP related Operating System: RedHat Linux 7.3 PHP Version: 4.3.4 New Comment: Here you go: [EMAIL PROTECTED] php-4.3.4]# gdb /usr/local/apache/bin/php GNU gdb Red Hat Linux (5.2-2) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-redhat-linux... (gdb) run /usr/docroot/dev/ldap2 Starting program: /usr/local/apache/bin/php /usr/docroot/dev/ldap2 [New Thread 1024 (LWP 19522)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 19522)] 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x400a20b4 in ldap_pvt_tls_check_hostname () from /usr/lib/libldap.so.2 #2 0x400a274f in ldap_int_tls_start () from /usr/lib/libldap.so.2 #3 0x40088ff1 in ldap_int_open_connection () from /usr/lib/libldap.so.2 #4 0x40097593 in ldap_new_connection () from /usr/lib/libldap.so.2 #5 0x40088a9a in ldap_open_defconn () from /usr/lib/libldap.so.2 #6 0x4009722f in ldap_send_initial_request () from /usr/lib/libldap.so.2 #7 0x40090be1 in ldap_sasl_bind () from /usr/lib/libldap.so.2 #8 0x40090c9a in ldap_sasl_bind_s () from /usr/lib/libldap.so.2 #9 0x4009138c in ldap_simple_bind_s () from /usr/lib/libldap.so.2 #10 0x40088a49 in ldap_bind_s () from /usr/lib/libldap.so.2 #11 0x080c7872 in zif_ldap_bind (ht=3, return_value=0x8366d14, this_ptr=0x0, return_value_used=1) at /root/php-4.3.4/ext/ldap/ldap.c:460 #12 0x081b49c4 in execute (op_array=0x8357b74) at /root/php-4.3.4/Zend/zend_execute.c:1616 #13 0x081a2410 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /root/php-4.3.4/Zend/zend.c:884 #14 0x0817af58 in php_execute_script (primary_file=0xbaa0) at /root/php-4.3.4/main/main.c:1729 #15 0x081bcec8 in main (argc=2, argv=0xbb44) at /root/php-4.3.4/sapi/cli/php_cli.c:819 #16 0x407401c4 in __libc_start_main () from /lib/libc.so.6 (gdb) frame 1024 #0 0x in ?? () (gdb) frame 3 #3 0x40088ff1 in ldap_int_open_connection () from /usr/lib/libldap.so.2 (gdb) frame 16 #16 0x407401c4 in __libc_start_main () from /lib/libc.so.6 (gdb) bt #0 0x in ?? () #1 0x400a20b4 in ldap_pvt_tls_check_hostname () from /usr/lib/libldap.so.2 #2 0x400a274f in ldap_int_tls_start () from /usr/lib/libldap.so.2 #3 0x40088ff1 in ldap_int_open_connection () from /usr/lib/libldap.so.2 #4 0x40097593 in ldap_new_connection () from /usr/lib/libldap.so.2 #5 0x40088a9a in ldap_open_defconn () from /usr/lib/libldap.so.2 #6 0x4009722f in ldap_send_initial_request () from /usr/lib/libldap.so.2 #7 0x40090be1 in ldap_sasl_bind () from /usr/lib/libldap.so.2 #8 0x40090c9a in ldap_sasl_bind_s () from /usr/lib/libldap.so.2 #9 0x4009138c in ldap_simple_bind_s () from /usr/lib/libldap.so.2 #10 0x40088a49 in ldap_bind_s () from /usr/lib/libldap.so.2 #11 0x080c7872 in zif_ldap_bind (ht=3, return_value=0x8366d14, this_ptr=0x0, return_value_used=1) at /root/php-4.3.4/ext/ldap/ldap.c:460 #12 0x081b49c4 in execute (op_array=0x8357b74) at /root/php-4.3.4/Zend/zend_execute.c:1616 #13 0x081a2410 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /root/php-4.3.4/Zend/zend.c:884 #14 0x0817af58 in php_execute_script (primary_file=0xbaa0) at /root/php-4.3.4/main/main.c:1729 #15 0x081bcec8 in main (argc=2, argv=0xbb44) at /root/php-4.3.4/sapi/cli/php_cli.c:819 #16 0x407401c4 in __libc_start_main () from /lib/libc.so.6 (gdb) frame 12 #12 0x081b49c4 in execute (op_array=0x8357b74) at /root/php-4.3.4/Zend/zend_execute.c:1616 1616 ((zend_internal_function *) EX(function_state).function)-handler(EX(opline)-extended_value, EX(Ts)[EX(opline)-result.u.var].var.ptr, EX(object).ptr, return_value_used TSRMLS_CC); (gdb) print (char *)(executor_globals.function_state_ptr-function)-common.function_name $1 = 0x8242abc ldap_bind $1 = 0x8242abc ldap_bind About the Oci libs note: OCI8 Support enabled Revision $Revision: 1.183.2.5 $ Oracle Version 8.1 Compile-time ORACLE_HOME /u01/app/oracle/product/8.1.6 Libraries Used no value I cannot point the ldap path there as there is no ldap libs in this oracle setup. Oracle is funcitoning fine. Note also it works with version 4.3.2-RC with the exact same buildpath. Previous Comments: [2003-11-25 15:40:29] [EMAIL PROTECTED] Actually..when using Oracle with PHP, you should point --with-ldap to that too..they're nice people and have put their own ldap functions into their libs. This conflicts with the openldap functions
#26409 [Opn]: ldap_bind is causing a seg fault
ID: 26409 User updated by: pyrox_pro at hotmail dot com Reported By: pyrox_pro at hotmail dot com Status: Open Bug Type: LDAP related Operating System: RedHat Linux 7.3 PHP Version: 4.3.4 New Comment: I did as requested, added my Oracle libs and built php with the configure line pointing ldap to them. Now I am getting: Warning: ldap_error(): supplied argument is not a valid ldap link resource in /usr/docroot/dev/ldap.php on line 14 Warning: ldap_bind() expects parameter 1 to be resource, boolean given in /usr/docroot/dev/ldap.php on line 15 $ds=ldap_connect(ldaps://myhostnameishere/); echo ldap_error($ds); $r=ldap_bind($ds,$ldap['user'],$ldap['pass']); Still not functional. This kind of problem defies logic. Should it not return either: A) A link ref B) False ?? The code in the manual is not function now either. Previous Comments: [2003-11-25 15:48:49] pyrox_pro at hotmail dot com Here you go: [EMAIL PROTECTED] php-4.3.4]# gdb /usr/local/apache/bin/php GNU gdb Red Hat Linux (5.2-2) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-redhat-linux... (gdb) run /usr/docroot/dev/ldap2 Starting program: /usr/local/apache/bin/php /usr/docroot/dev/ldap2 [New Thread 1024 (LWP 19522)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 19522)] 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x400a20b4 in ldap_pvt_tls_check_hostname () from /usr/lib/libldap.so.2 #2 0x400a274f in ldap_int_tls_start () from /usr/lib/libldap.so.2 #3 0x40088ff1 in ldap_int_open_connection () from /usr/lib/libldap.so.2 #4 0x40097593 in ldap_new_connection () from /usr/lib/libldap.so.2 #5 0x40088a9a in ldap_open_defconn () from /usr/lib/libldap.so.2 #6 0x4009722f in ldap_send_initial_request () from /usr/lib/libldap.so.2 #7 0x40090be1 in ldap_sasl_bind () from /usr/lib/libldap.so.2 #8 0x40090c9a in ldap_sasl_bind_s () from /usr/lib/libldap.so.2 #9 0x4009138c in ldap_simple_bind_s () from /usr/lib/libldap.so.2 #10 0x40088a49 in ldap_bind_s () from /usr/lib/libldap.so.2 #11 0x080c7872 in zif_ldap_bind (ht=3, return_value=0x8366d14, this_ptr=0x0, return_value_used=1) at /root/php-4.3.4/ext/ldap/ldap.c:460 #12 0x081b49c4 in execute (op_array=0x8357b74) at /root/php-4.3.4/Zend/zend_execute.c:1616 #13 0x081a2410 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /root/php-4.3.4/Zend/zend.c:884 #14 0x0817af58 in php_execute_script (primary_file=0xbaa0) at /root/php-4.3.4/main/main.c:1729 #15 0x081bcec8 in main (argc=2, argv=0xbb44) at /root/php-4.3.4/sapi/cli/php_cli.c:819 #16 0x407401c4 in __libc_start_main () from /lib/libc.so.6 (gdb) frame 1024 #0 0x in ?? () (gdb) frame 3 #3 0x40088ff1 in ldap_int_open_connection () from /usr/lib/libldap.so.2 (gdb) frame 16 #16 0x407401c4 in __libc_start_main () from /lib/libc.so.6 (gdb) bt #0 0x in ?? () #1 0x400a20b4 in ldap_pvt_tls_check_hostname () from /usr/lib/libldap.so.2 #2 0x400a274f in ldap_int_tls_start () from /usr/lib/libldap.so.2 #3 0x40088ff1 in ldap_int_open_connection () from /usr/lib/libldap.so.2 #4 0x40097593 in ldap_new_connection () from /usr/lib/libldap.so.2 #5 0x40088a9a in ldap_open_defconn () from /usr/lib/libldap.so.2 #6 0x4009722f in ldap_send_initial_request () from /usr/lib/libldap.so.2 #7 0x40090be1 in ldap_sasl_bind () from /usr/lib/libldap.so.2 #8 0x40090c9a in ldap_sasl_bind_s () from /usr/lib/libldap.so.2 #9 0x4009138c in ldap_simple_bind_s () from /usr/lib/libldap.so.2 #10 0x40088a49 in ldap_bind_s () from /usr/lib/libldap.so.2 #11 0x080c7872 in zif_ldap_bind (ht=3, return_value=0x8366d14, this_ptr=0x0, return_value_used=1) at /root/php-4.3.4/ext/ldap/ldap.c:460 #12 0x081b49c4 in execute (op_array=0x8357b74) at /root/php-4.3.4/Zend/zend_execute.c:1616 #13 0x081a2410 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /root/php-4.3.4/Zend/zend.c:884 #14 0x0817af58 in php_execute_script (primary_file=0xbaa0) at /root/php-4.3.4/main/main.c:1729 #15 0x081bcec8 in main (argc=2, argv=0xbb44) at /root/php-4.3.4/sapi/cli/php_cli.c:819 #16 0x407401c4 in __libc_start_main () from /lib/libc.so.6 (gdb) frame 12 #12 0x081b49c4 in execute (op_array=0x8357b74) at /root/php-4.3.4/Zend/zend_execute.c:1616 1616 ((zend_internal_function *) EX(function_state).function)-handler(EX(opline)-extended_value, EX(Ts)[EX(opline)-result.u.var].var.ptr, EX(object).ptr, return_value_used TSRMLS_CC); (gdb) print (char *)(executor_globals.function_state_ptr-function)-common.function_name $1 = 0x8242abc
#26409 [Opn]: ldap_bind is causing a seg fault
ID: 26409 User updated by: pyrox_pro at hotmail dot com Reported By: pyrox_pro at hotmail dot com Status: Open Bug Type: LDAP related Operating System: RedHat Linux 7.3 PHP Version: 4.3.4 New Comment: Would the problem be the Oracle 8 libs are older and do not support the Openldap 2 style of hostname definition, and possibly do not support SSL? Either way I have been punked. Previous Comments: [2003-11-25 16:52:21] pyrox_pro at hotmail dot com I did as requested, added my Oracle libs and built php with the configure line pointing ldap to them. Now I am getting: Warning: ldap_error(): supplied argument is not a valid ldap link resource in /usr/docroot/dev/ldap.php on line 14 Warning: ldap_bind() expects parameter 1 to be resource, boolean given in /usr/docroot/dev/ldap.php on line 15 $ds=ldap_connect(ldaps://myhostnameishere/); echo ldap_error($ds); $r=ldap_bind($ds,$ldap['user'],$ldap['pass']); Still not functional. This kind of problem defies logic. Should it not return either: A) A link ref B) False ?? The code in the manual is not function now either. [2003-11-25 15:48:49] pyrox_pro at hotmail dot com Here you go: [EMAIL PROTECTED] php-4.3.4]# gdb /usr/local/apache/bin/php GNU gdb Red Hat Linux (5.2-2) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-redhat-linux... (gdb) run /usr/docroot/dev/ldap2 Starting program: /usr/local/apache/bin/php /usr/docroot/dev/ldap2 [New Thread 1024 (LWP 19522)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 19522)] 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x400a20b4 in ldap_pvt_tls_check_hostname () from /usr/lib/libldap.so.2 #2 0x400a274f in ldap_int_tls_start () from /usr/lib/libldap.so.2 #3 0x40088ff1 in ldap_int_open_connection () from /usr/lib/libldap.so.2 #4 0x40097593 in ldap_new_connection () from /usr/lib/libldap.so.2 #5 0x40088a9a in ldap_open_defconn () from /usr/lib/libldap.so.2 #6 0x4009722f in ldap_send_initial_request () from /usr/lib/libldap.so.2 #7 0x40090be1 in ldap_sasl_bind () from /usr/lib/libldap.so.2 #8 0x40090c9a in ldap_sasl_bind_s () from /usr/lib/libldap.so.2 #9 0x4009138c in ldap_simple_bind_s () from /usr/lib/libldap.so.2 #10 0x40088a49 in ldap_bind_s () from /usr/lib/libldap.so.2 #11 0x080c7872 in zif_ldap_bind (ht=3, return_value=0x8366d14, this_ptr=0x0, return_value_used=1) at /root/php-4.3.4/ext/ldap/ldap.c:460 #12 0x081b49c4 in execute (op_array=0x8357b74) at /root/php-4.3.4/Zend/zend_execute.c:1616 #13 0x081a2410 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /root/php-4.3.4/Zend/zend.c:884 #14 0x0817af58 in php_execute_script (primary_file=0xbaa0) at /root/php-4.3.4/main/main.c:1729 #15 0x081bcec8 in main (argc=2, argv=0xbb44) at /root/php-4.3.4/sapi/cli/php_cli.c:819 #16 0x407401c4 in __libc_start_main () from /lib/libc.so.6 (gdb) frame 1024 #0 0x in ?? () (gdb) frame 3 #3 0x40088ff1 in ldap_int_open_connection () from /usr/lib/libldap.so.2 (gdb) frame 16 #16 0x407401c4 in __libc_start_main () from /lib/libc.so.6 (gdb) bt #0 0x in ?? () #1 0x400a20b4 in ldap_pvt_tls_check_hostname () from /usr/lib/libldap.so.2 #2 0x400a274f in ldap_int_tls_start () from /usr/lib/libldap.so.2 #3 0x40088ff1 in ldap_int_open_connection () from /usr/lib/libldap.so.2 #4 0x40097593 in ldap_new_connection () from /usr/lib/libldap.so.2 #5 0x40088a9a in ldap_open_defconn () from /usr/lib/libldap.so.2 #6 0x4009722f in ldap_send_initial_request () from /usr/lib/libldap.so.2 #7 0x40090be1 in ldap_sasl_bind () from /usr/lib/libldap.so.2 #8 0x40090c9a in ldap_sasl_bind_s () from /usr/lib/libldap.so.2 #9 0x4009138c in ldap_simple_bind_s () from /usr/lib/libldap.so.2 #10 0x40088a49 in ldap_bind_s () from /usr/lib/libldap.so.2 #11 0x080c7872 in zif_ldap_bind (ht=3, return_value=0x8366d14, this_ptr=0x0, return_value_used=1) at /root/php-4.3.4/ext/ldap/ldap.c:460 #12 0x081b49c4 in execute (op_array=0x8357b74) at /root/php-4.3.4/Zend/zend_execute.c:1616 #13 0x081a2410 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /root/php-4.3.4/Zend/zend.c:884 #14 0x0817af58 in php_execute_script (primary_file=0xbaa0) at /root/php-4.3.4/main/main.c:1729 #15 0x081bcec8 in main (argc=2, argv=0xbb44) at /root/php-4.3.4/sapi/cli/php_cli.c:819 #16 0x407401c4 in __libc_start_main () from /lib/libc.so.6 (gdb) frame 12 #12 0x081b49c4 in execute (op_array=0x8357b74) at /root/php-4.3.4/Zend/zend_execute.c:1616 1616
#22686 [Fbk-Opn]: ldap_get_entries crash with no error.
ID: 22686
User updated by: pyrox_pro at hotmail dot com
Reported By: pyrox_pro at hotmail dot com
-Status: Feedback
+Status: Open
Bug Type: LDAP related
Operating System: RedHat 7.3
PHP Version: 4.3.1
New Comment:
Thank you, but now I have a complaint.
At least it does something besides dying, but it appears it cannot
handle 580 items returned?
Fatal error: Allowed memory size of 9437200 bytes exhausted at (null):0
(tried to allocate 35 bytes) in /usr/docroot/dev/softrack/ldap.php on
line 122
line 22 is of course:
$info=ldap_get_entries($ds, $sr);
It this just a limitation I will have to deal with? 580 seems like a
relativley low number?
Previous Comments:
[2003-03-13 16:22:37] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2003-03-13 16:20:06] pyrox_pro at hotmail dot com
For a description that looks pretty, go here:
http://www.phpbuilder.com/board/showthread.php?s=threadid=10232112
This code worked awhile back. Seems like it was working a few versions
back. Now it just dies, no errors to screen, no errors in apache logs,
not one thing anywhere. The output just stops at the function:
$info=ldap_get_entries($ds, $sr);
For no apparent reason. At first I thought it was outdated libs, so I
updated everything, openldap, openssl, php to 4.3.1 , ect.
Still nothing. It just dies with no output or explanation.
PHP:
$ds=ldap_connect(ldaps://.$ldap['SERV']./);
$r=ldap_bind($ds,$ldap['user'],$ldap['pass']);
if(ldap_errno($ds)) die(FONT COLOR=#ff.ldap_error($ds));
$sr=ldap_search($ds,OU=.stripslashes($agent).,
.$ldap['dn'].,CN=*);
if(ldap_errno($ds)) die(FONT COLOR=#ff.ldap_error($ds));
echo Number of entires returned is
.ldap_count_entries($ds,$sr).p;
echo Getting entries ...p;
flush();
$info=ldap_get_entries($ds, $sr);
echo Data for .$info[count]. items returned:p;
flush();
for ($i=0; $i$info[count]; $i++) {
echo dn is: . $info[$i][dn] .br;
echo first cn entry is: . $info[$i][cn][0] .br;
echo first email entry is: . $info[$i][mail][0] .p;
}
echo Closing connection;
flush();
The output when run looks like this:
Number of entires returned is 580
Getting entries ...
And thats it, just sudden death. I view the page source just to be
sure. And like I said, there is squat in the logs about any errors.
Much of this code is pulled directly from the manual or tutorials.
It used to work, some event caused it to fail.
( I went from php 4.2.2 to php 4.3 )
I have searched google, the php.net bug lists, ect.
--
Edit this bug report at http://bugs.php.net/?id=22686edit=1
#22686 [Fbk-Opn]: ldap_get_entries crash with no error.
ID: 22686
User updated by: pyrox_pro at hotmail dot com
Reported By: pyrox_pro at hotmail dot com
-Status: Feedback
+Status: Open
Bug Type: LDAP related
Operating System: RedHat 7.3
PHP Version: 4.3.1
New Comment:
That is the 8mb standard, what do you suggest I raise it to then?
Previous Comments:
[2003-03-14 10:02:56] [EMAIL PROTECTED]
Check your memory_limit setting, that is what probably limiting your
memory usage to 9437200 bytes and thus preventing usage of more then
580 items.
[2003-03-14 09:53:18] pyrox_pro at hotmail dot com
Thank you, but now I have a complaint.
At least it does something besides dying, but it appears it cannot
handle 580 items returned?
Fatal error: Allowed memory size of 9437200 bytes exhausted at (null):0
(tried to allocate 35 bytes) in /usr/docroot/dev/softrack/ldap.php on
line 122
line 22 is of course:
$info=ldap_get_entries($ds, $sr);
It this just a limitation I will have to deal with? 580 seems like a
relativley low number?
[2003-03-13 16:22:37] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2003-03-13 16:20:06] pyrox_pro at hotmail dot com
For a description that looks pretty, go here:
http://www.phpbuilder.com/board/showthread.php?s=threadid=10232112
This code worked awhile back. Seems like it was working a few versions
back. Now it just dies, no errors to screen, no errors in apache logs,
not one thing anywhere. The output just stops at the function:
$info=ldap_get_entries($ds, $sr);
For no apparent reason. At first I thought it was outdated libs, so I
updated everything, openldap, openssl, php to 4.3.1 , ect.
Still nothing. It just dies with no output or explanation.
PHP:
$ds=ldap_connect(ldaps://.$ldap['SERV']./);
$r=ldap_bind($ds,$ldap['user'],$ldap['pass']);
if(ldap_errno($ds)) die(FONT COLOR=#ff.ldap_error($ds));
$sr=ldap_search($ds,OU=.stripslashes($agent).,
.$ldap['dn'].,CN=*);
if(ldap_errno($ds)) die(FONT COLOR=#ff.ldap_error($ds));
echo Number of entires returned is
.ldap_count_entries($ds,$sr).p;
echo Getting entries ...p;
flush();
$info=ldap_get_entries($ds, $sr);
echo Data for .$info[count]. items returned:p;
flush();
for ($i=0; $i$info[count]; $i++) {
echo dn is: . $info[$i][dn] .br;
echo first cn entry is: . $info[$i][cn][0] .br;
echo first email entry is: . $info[$i][mail][0] .p;
}
echo Closing connection;
flush();
The output when run looks like this:
Number of entires returned is 580
Getting entries ...
And thats it, just sudden death. I view the page source just to be
sure. And like I said, there is squat in the logs about any errors.
Much of this code is pulled directly from the manual or tutorials.
It used to work, some event caused it to fail.
( I went from php 4.2.2 to php 4.3 )
I have searched google, the php.net bug lists, ect.
--
Edit this bug report at http://bugs.php.net/?id=22686edit=1
#22686 [Bgs]: ldap_get_entries crash with no error.
ID: 22686 User updated by: pyrox_pro at hotmail dot com Reported By: pyrox_pro at hotmail dot com Status: Bogus Bug Type: LDAP related Operating System: RedHat 7.3 PHP Version: 4.3.1 New Comment: How is this classified as 'Bogus' ?! It should have been saved and closed, not Bogus.. There definatley WAS a bug, and the 4.3.2 RC fixed it. The memory questions were just extra. Previous Comments: [2003-03-14 10:42:35] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Depends on your needs, if you know you'll need to load 1000 elements to memory then 20 meg limit would probably be a good idea and so on... Since this is not a bug in PHP I am closing this report. [2003-03-14 10:38:23] pyrox_pro at hotmail dot com That is the 8mb standard, what do you suggest I raise it to then? [2003-03-14 10:02:56] [EMAIL PROTECTED] Check your memory_limit setting, that is what probably limiting your memory usage to 9437200 bytes and thus preventing usage of more then 580 items. [2003-03-14 09:53:18] pyrox_pro at hotmail dot com Thank you, but now I have a complaint. At least it does something besides dying, but it appears it cannot handle 580 items returned? Fatal error: Allowed memory size of 9437200 bytes exhausted at (null):0 (tried to allocate 35 bytes) in /usr/docroot/dev/softrack/ldap.php on line 122 line 22 is of course: $info=ldap_get_entries($ds, $sr); It this just a limitation I will have to deal with? 580 seems like a relativley low number? [2003-03-13 16:22:37] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/22686 -- Edit this bug report at http://bugs.php.net/?id=22686edit=1
#22686 [Bgs-Csd]: ldap_get_entries crash with no error.
ID: 22686 User updated by: pyrox_pro at hotmail dot com Reported By: pyrox_pro at hotmail dot com -Status: Bogus +Status: Closed Bug Type: LDAP related Operating System: RedHat 7.3 PHP Version: 4.3.1 New Comment: How is this classified as 'Bogus' ?! It should have been saved and closed, not Bogus.. There definatley WAS a bug, and the 4.3.2 RC fixed it. The memory questions were just extra. Previous Comments: [2003-03-14 13:20:42] pyrox_pro at hotmail dot com How is this classified as 'Bogus' ?! It should have been saved and closed, not Bogus.. There definatley WAS a bug, and the 4.3.2 RC fixed it. The memory questions were just extra. [2003-03-14 10:42:35] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Depends on your needs, if you know you'll need to load 1000 elements to memory then 20 meg limit would probably be a good idea and so on... Since this is not a bug in PHP I am closing this report. [2003-03-14 10:38:23] pyrox_pro at hotmail dot com That is the 8mb standard, what do you suggest I raise it to then? [2003-03-14 10:02:56] [EMAIL PROTECTED] Check your memory_limit setting, that is what probably limiting your memory usage to 9437200 bytes and thus preventing usage of more then 580 items. [2003-03-14 09:53:18] pyrox_pro at hotmail dot com Thank you, but now I have a complaint. At least it does something besides dying, but it appears it cannot handle 580 items returned? Fatal error: Allowed memory size of 9437200 bytes exhausted at (null):0 (tried to allocate 35 bytes) in /usr/docroot/dev/softrack/ldap.php on line 122 line 22 is of course: $info=ldap_get_entries($ds, $sr); It this just a limitation I will have to deal with? 580 seems like a relativley low number? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/22686 -- Edit this bug report at http://bugs.php.net/?id=22686edit=1
#22686 [NEW]: ldap_get_entries crash with no error.
From: pyrox_pro at hotmail dot com
Operating system: RedHat 7.3
PHP version: 4.3.1
PHP Bug Type: LDAP related
Bug description: ldap_get_entries crash with no error.
For a description that looks pretty, go here:
http://www.phpbuilder.com/board/showthread.php?s=threadid=10232112
This code worked awhile back. Seems like it was working a few versions
back. Now it just dies, no errors to screen, no errors in apache logs, not
one thing anywhere. The output just stops at the function:
$info=ldap_get_entries($ds, $sr);
For no apparent reason. At first I thought it was outdated libs, so I
updated everything, openldap, openssl, php to 4.3.1 , ect.
Still nothing. It just dies with no output or explanation.
PHP:
$ds=ldap_connect(ldaps://.$ldap['SERV']./);
$r=ldap_bind($ds,$ldap['user'],$ldap['pass']);
if(ldap_errno($ds)) die(FONT COLOR=#ff.ldap_error($ds));
$sr=ldap_search($ds,OU=.stripslashes($agent).,
.$ldap['dn'].,CN=*);
if(ldap_errno($ds)) die(FONT COLOR=#ff.ldap_error($ds));
echo Number of entires returned is .ldap_count_entries($ds,$sr).p;
echo Getting entries ...p;
flush();
$info=ldap_get_entries($ds, $sr);
echo Data for .$info[count]. items returned:p;
flush();
for ($i=0; $i$info[count]; $i++) {
echo dn is: . $info[$i][dn] .br;
echo first cn entry is: . $info[$i][cn][0] .br;
echo first email entry is: . $info[$i][mail][0] .p;
}
echo Closing connection;
flush();
The output when run looks like this:
Number of entires returned is 580
Getting entries ...
And thats it, just sudden death. I view the page source just to be sure.
And like I said, there is squat in the logs about any errors.
Much of this code is pulled directly from the manual or tutorials.
It used to work, some event caused it to fail.
( I went from php 4.2.2 to php 4.3 )
I have searched google, the php.net bug lists, ect.
--
Edit bug report at http://bugs.php.net/?id=22686edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22686r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=22686r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=22686r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22686r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=22686r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22686r=support
Expected behavior: http://bugs.php.net/fix.php?id=22686r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22686r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22686r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=22686r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22686r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=22686r=dst
IIS Stability: http://bugs.php.net/fix.php?id=22686r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22686r=gnused
