PHP5 + oci8 consistently segfaults on script exit

Gordon Stratton tsr2600 at gmail.com
Thu Jul 26 01:03:32 UTC 2007


Hey,

I'm running FreeBSD 6.2-RELEASE-p1 and PHP 5.2.2 built with the oci8
extension which is built against the oracle8-client port version
0.1.1_1.

Connecting to and working with an Oracle database works well so far, but
PHP segfaults whenever any script that uses the oci8 extension is run
and exits (regardless of success or failure).  The segfault _only_
occurs when PHP is tearing everything down after the script runs.
Therefore scripts run successfully, but my kernel logs look like this:

Jul 25 16:59:17 kernel: pid 89667 (php), uid 1003: exited on signal 11
Jul 25 17:00:11 kernel: pid 89725 (php), uid 1003: exited on signal 11
Jul 25 17:01:38 kernel: pid 89729 (php), uid 1003: exited on signal 11
Jul 25 17:02:58 kernel: pid 89732 (php), uid 1003: exited on signal 11
...

Using gdb I've tracked the segfault down to a call to dlclose (via the
macro DL_UNLOAD in Zend/zend_API.c on line 1916).  The module being
unloaded when the segfault occurs is the oci extension.

So far, I've tried:

- Various combinations of environment variables per the PHP
  documentation

- Messing around remapping symbols as outlined in README.PORT that
  ships with oracle8-client and rebuilding oci8 each time

- Not loading other PHP extensions

- Loading other PHP extensions in a different order

- Googling until I've memorized the 10 or so pages related to my problem

The problem has persisted across multiple versions of PHP in the last
several months, and pretty much everything I've tried results in a
working oci8 with the segfault after the script finishes.  Today we
experienced some very odd behavior with a large Oracle query and httpd
exiting on signal 4 and while they may not be related, I'd like to see
if it's at all possible to resolve this issue (in the spirit of ruling
things out).  Anything is welcome, I've heard of at least one other
person with my problem (and nearly identical setup) so I don't think I'm
the only one out there.

Thanks for your time,

Gordon


More information about the freebsd-database mailing list