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.
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 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=0xbffffaa0) at
/root/php-4.3.4/main/main.c:1729
#15 0x081b2984 in main (argc=2, argv=0xbffffb44) 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..


------------------------------------------------------------------------

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=26409&edit=1

Reply via email to