I had a strange bug with OCIBindByName, that is PHP/Apache caused a segementation failure (Apache says someting like
FATAL:  emalloc():  Unable to allocate 536870912 bytes).

The bug is not easy to reproduce, thus I try to explain how it works:

I'm using lot of classes/objects in my project, pasing this objects by reference to functions/methods.
Also, all my OCI-related stuff is written in a single class, a method for each database io use case.

E.g.

01: class DataFactoryOCI {
02: ...
03: function writeFoo( &$i_FooObject) {
04:   ...
05:   $iStmt = $this->createStatement(...);
06:   // bind values
07:   $strMember =& $i_FooObject->getMember();
08:   OCIBindByName ( $iStmt, ':member', &$strMember, -1 );
09:   // execute
10:   ...
11: }

This method works fine. And my program works fine in most cases. And that's the problem: 'most' is not 'all'.
In my special case (web-environment) the program sends a redirect to the user.
My log-files show me that the redirect is successfull, the writeFoo-method called before the redirect (and exit) functions is working fine, all data are written in the database (that is, all transaction are committed succesfully), my whole program is working fine.
But: PHP/Apache crashes!

What was happening: In some cases other methods are using methods of the object passed to writeFoo - and this seems to cause some trouble. I'm not sure what really caused the error, at least I'm sure that all Foo-method calls didn't changed the object's state (the object/class Foo is immutable, the written member is used as a foreign key).

IMHO it seems to be a bug in PHP/OCI8 when destructing the objects, specially if an object or member of an object was bind by OCIBindByName.
I fixed the bug in my case by creating a local copy of the member, that is simply changed line 07:

from 07:   $strMember =& $i_FooObject->getMember();
into 07:   $strMember = $i_FooObject->getMember();

With this line, all tested cases are working.