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..

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:

[root@linuxdev01 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.

It crashes inside the ldap libs -> Not PHP bug. (report to openldap folks)

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.

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.

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?

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..

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.

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..

What version of openldap are you using with that and on what OS?

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.

It's still not PHP bug, but do try this:

1) Remove all (and I mean ALL) openldap related header files and libraries.
2) Install the latest openldap from sources (!) using this configure line: ./configure --prefix=/opt/openldap 
3) Get fresh PHP sources, and compile it with this configure line: 
# ./configure --disable-all --disable-cgi --enable-debug --with-ldap=/opt/openldap

If you can reproduce this crash with the created sapi/cli/php binary reopen this bug report.

I got similar error -- on ldap_bind () my php script segfaults...

I have two machines, both with OpenLDAP 2.0.27 and PHP 4.3.4  with ldap support (--with-ldap=/usr)

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

two running the same ldap authentication function, on first machine it gets segfault, on second server function works perfectly...

PTW ldapsearch (from OpenLDAP 2.0.27) gets segfault on both machines...

OK, I've found out that my problem lies in openssl-0.9.7c libraries.

Making ldap:// connection (with PHP's ldap_bind () or OpenLDAP's ldapsearch) worked perfectly, but since I'm trying to authenticate users via binding them to the server with username/password, ldaps:// is required (for quite obvious reasons). And here ldap_bind (as well as ldapsearch) segfaults.

So I'm going to try rebuilding php / openldap with older openssl libs (it worked with openssl-0.9.6k).

Had the same problem with the apache + php segfaulting. Just wanted to confirm that the setup actually worked if openssl 0.9.6l was used and not the openssl 0.9.7c.