ID: 31533
User updated by: martin dot pala at oskar dot cz
Reported By: martin dot pala at oskar dot cz
-Status: Feedback
+Status: Open
Bug Type: OCI8 related
Operating System: Solaris 9
-PHP Version: 5.0.3
+PHP Version: 5.0.x
New Comment:
We did extensive testing - here is result and possible workarounds:
I. the crash in _oci_close_session is solaris-related only and it
happens only if persistent connections are used.
---
We did following tests:
1.) solaris9 + apache-1.3.31 + php5-STABLE snapshot (5.0.4-devel) + OCI
8.1.7
[result: CRASH]
2.) solaris9 + apache-1.3.31 + php5-STABLE snapshot (5.0.4-devel) + OCI
9.2.0.1
[result: CRASH]
3.) solaris9 + apache-1.3.31 + php5-STABLE snapshot (5.0.4-devel) + OCI
10.1.0.3
[result: CRASH]
4.) solaris9 + apache-2.0.52 + php-5.0.[23] + OCI 9.2.0.1
[result: CRASH]
5.) linux (redhat 7.3) + apache-1.3.27 + php5-STABLE snapshot
(5.0.4-devel) + OCI 10.1.0.3
[result: STABLE]
There is also PHP Bug #24531 reported which describes the same error on
Solaris8 and PHP-4.x.
The core backtrace shows the crash in _oci_close_session ->
OCIHandleAlloc() -> kpughndl0() or kpusattr() functions (both
libclntsh.so library):
core '/usr/apache/core' of 13559: /usr/apache/bin/httpd
fc99b9a8 kpughndl0 (3, 0, 3, 0, f8e9d800, 2) + 78
fd8c035c _oci_close_session (ac7520, 15, ffbff094, fdcc2240, fdcc222c,
ac7520) + 6c
fd9d7900 list_entry_destructor (6b2ac8, 75c00, 10, 512310, 0, 252a0) +
74
fd9d657c zend_hash_apply_deleter (fdcc65d0, 43d5c0, 10, 5ad1cba6,
5122e0, 3181d0) + 194
fd9d6604 zend_hash_graceful_reverse_destroy (fdcc65d0, fd9c0540, 0, 0,
0, 0) + 14
fd9c14ec shutdown_executor (0, fd9ce650, 0, 0, 0, 0) + 2b8
fd9ce6a0 zend_deactivate (fdcc6c34, fd990e30, 0, ffbff5f8, 0, 0) + bc
fd990ed4 php_request_shutdown (0, fda0e308, 0, ffbff5f8, 0, 0) + 258
fda0e39c apache_php_module_main (ffffffff, 0, 0, ffbff6d8, 0, 0) +
158
fda0ee7c send_php (ffffffff, 0, 0, 0, 0, 0) + 334
fda0f0f8 send_parsed_php (3384d8, fdbb1aa7, ffffffff, 0, 70, 70) + 18
0001c090 ap_invoke_handler (3384d8, 25, 1, 6fc00, 33b2c8, 5) + f8
0002fd6c ???????? (3384d8, fe2f0b88, 1, ffbff964, 4, 1)
0002fdbc ap_process_request (3384d8, 4, 3384d8, ffbff9e4, ffbff9d4,
12) + 28
00027be8 ???????? (77c00, 77c00, 77c00, 10, 6fc00, 26000)
00027df8 ???????? (7aa28, 12, 41ee7f47, 12, 51, 76d68)
000286a8 ???????? (77c00, 77c00, 77c00, 8, 0, 6fc00)
00028dd8 main (1, ffbffbdc, ffbffbe4, 6fc00, 0, 0) + 34c
00017a70 _start (0, 0, 0, 0, 0, 0) + 108
core '/usr/apache/core' of 12472: /usr/apache/bin/httpd
fc978480 kpusattr (0, 3, 74de78, 0, 6, 168f6c) + 9c
fd8c039c _oci_close_session (702268, 15, ffbfefac, fdcc2240, fdcc222c,
702268) + ac
fd9d7900 list_entry_destructor (6d61c8, 75c00, 10, 266d10, 0, 252a0) +
74
fd9d657c zend_hash_apply_deleter (fdcc65d0, 6d5e80, 10, 5ad1cba6,
266ce0, 239ed0) + 194
fd9d6604 zend_hash_graceful_reverse_destroy (fdcc65d0, fd9c0540, 0, 0,
0, 0) + 14
fd9c14ec shutdown_executor (0, fd9ce650, 0, 0, 0, 0) + 2b8
fd9ce6a0 zend_deactivate (fdcc6c34, fd990e30, 0, ffbff510, 0, 0) + bc
fd990ed4 php_request_shutdown (0, fda0e308, 0, ffbff510, 0, 0) + 258
fda0e39c apache_php_module_main (ffffffff, 0, 0, ffbff5f0, 0, 0) +
158
fda0ee7c send_php (ffffffff, 0, 0, 0, 0, 0) + 334
fda0f0f8 send_parsed_php (259bc8, fdbb1aa7, ffffffff, 0, 70, 70) + 18
0001c090 ap_invoke_handler (259bc8, 25, 1, 6fc00, 25c9e8, 6) + f8
0002fd6c ???????? (259bc8, fe2f03d8, 1, ffbff87c, 4, 1)
0002fdbc ap_process_request (259bc8, 4, 259bc8, ffbff8fc, ffbff8ec, 6)
+ 28
00027be8 ???????? (77c00, 77c00, 77c00, 10, 6fc00, 26000)
00027df8 ???????? (7aa28, 6, 41ee7c91, 0, ffbffa60, 1)
00028148 ???????? (7, 7, 75fc0, 6fc00, 75c00, 6fc00)
00028728 ???????? (77c00, 77c00, 77c00, 8, 0, 6fc00)
00028dd8 main (1, ffbffbdc, ffbffbe4, 6fc00, 0, 0) + 34c
00017a70 _start (0, 0, 0, 0, 0, 0) + 108
II. possible workarounds:
---
1.) to decrease the crash count it helped to initalize the OCI using
OCI_THREADED flag (which is not used in PHP by default).
When was apache running as single process (using -X) it was stable in
one PHP script which can
we used to 100% replicate the crash. When was apache running normaly
with preforked child worker processes (not threads), it crashed.
With bellow patch (OCI_THREADED flag) it worked without problems this
script. However, we found later another script which caused
crash in _oci_close_session again => this patch doesn't solve the
problem (though the crash ratio descreased significantly).
--8<--
diff -Naur php-5.0.3/ext/oci8/oci8.c php-5.0.3-mp/ext/oci8/oci8.c
--- php-5.0.3/ext/oci8/oci8.c 2004-11-22 22:46:49.000000000 +0100
+++ php-5.0.3-mp/ext/oci8/oci8.c 2005-01-11 14:20:56.802128000
+0100
@@ -622,11 +622,7 @@
#endif
-#ifdef ZTS
#define PHP_OCI_INIT_MODE PHP_OCI_INIT_MODE_TMP | OCI_THREADED
-#else
-#define PHP_OCI_INIT_MODE PHP_OCI_INIT_MODE_TMP
-#endif
mutex_alloc(mx_lock);
--8<--
2.) It works better with lot of preforked childs with unlimited life.
We compared following apache test configurations:
MinSpareServers 25
MaxSpareServers 50
StartServers 75
MaxClients 150
MaxRequestsPerChild 0
and
MinSpareServers 5
MaxSpareServers 10
StartServers 5
MaxClients 150
MaxRequestsPerChild 5
Using the same requests count, the first configuration achieved ca. 10x
less crashes then the second one (where childs are restarted very
often).
3.) Final and "best" workaround: don't use persistent connections at
all
When we switched the scripts to not use persistent connections, PHP was
stable (this solution was confirmed in PHP Bug #24531 too).
III. Summary:
---
The PHP module OCI persistent connections on solaris are very
unstable.
It is question where the problem is (solaris libraries? / solaris
version of OCI library? / PHP?) ... it works on linux like a charm.
Previous Comments:
------------------------------------------------------------------------
[2005-01-18 11:32:28] [EMAIL PROTECTED]
Ok, marking the report as waiting for feedback then.
------------------------------------------------------------------------
[2005-01-18 10:19:59] martin dot pala at oskar dot cz
I'm little bit busy, i'll try to trace the root cause later this week.
As i wrote in the report, in the case that apache is running as single
process (using -X option) it works well, if it runs in preforked childs
mode, PHP fails until OCI_THREADED flag is set ...
------------------------------------------------------------------------
[2005-01-14 21:27:34] [EMAIL PROTECTED]
Before making any changes I'd like to know why there are necessary.
As far as I know, OCI_THREADED is necessary only if you're using OCI in
threaded environment and is not necessary when you're using
Apache1/Apache2-prefork.
Could you plz give me more info about why Solaris requires this flag?
I'm sure it's Solaris-specific problem, as I do use OCI8 at Linux
without any problems for a long time.
------------------------------------------------------------------------
[2005-01-13 10:33:32] martin dot pala at oskar dot cz
Description:
------------
We are running PHP-5.0.3 and Apache-1.3.31 on Solaris 9. There is
application written in PHP which is able to crash PHP anytime specific
script which is using OCI extension is called. The backtrace is:
---8<---
core 'core' of 18430: /usr/apache/bin/httpd
fd8c038c _oci_close_session (636978, 15, ffbff014, fdcc2240, fdcc222c,
636978) + 9c
fd9d7900 list_entry_destructor (5d93c8, 75c00, 10, 2654f0, 0, 252a0) +
74
fd9d657c zend_hash_apply_deleter (fdcc65d0, 6bae80, 10, 5ad1cba6,
2654c0, 238710) + 194
fd9d6604 zend_hash_graceful_reverse_destroy (fdcc65d0, fd9c0540, 0, 0,
0, 0) + 14
fd9c14ec shutdown_executor (0, fd9ce650, 0, 0, 0, 0) + 2b8
fd9ce6a0 zend_deactivate (fdcc6c34, fd990e30, 0, ffbff578, 0, 0) + bc
fd990ed4 php_request_shutdown (0, fda0e308, 0, ffbff578, 0, 0) + 258
fda0e39c apache_php_module_main (ffffffff, 0, 0, ffbff658, 0, 0) +
158
fda0ee7c send_php (ffffffff, 0, 0, 0, 0, 0) + 334
fda0f0f8 send_parsed_php (258428, fdbb1aa7, ffffffff, 0, 70, 70) + 18
0001c090 ap_invoke_handler (258428, 25, 1, 6fc00, 25b438, 6) + f8
0002fd6c ???????? (258428, fe2f0148, 1, ffbff8e4, 4, 1)
0002fdbc ap_process_request (258428, 4, 258428, ffbff964, ffbff954, 2)
+ 28
00027be8 ???????? (77c00, 77c00, 77c00, 10, 6fc00, 26000)
00027df8 ???????? (7aa28, 2, 41e27c3a, 0, ffbffa40, 0)
00027eb4 ???????? (4, 0, 41e27c39, 0, 1, 76d68)
00028714 ???????? (77c00, 77c00, 77c00, 8, 0, 6fc00)
00028dd8 main (1, ffbffbbc, ffbffbc4, 6fc00, 0, 0) + 34c
00017a70 _start (0, 0, 0, 0, 0, 0) + 108
---8<---
I have tried latest PHP snapshot too - with the same result.
I tried then run Apache in single-process mode (using -X option). This
time it was stable.
Thereafter i found in the code of OCI extension (ext/oci8/oci8.c) the
dependency of OCI library initialization flag OCI_THREADED on PHP ZTS
option -> ZTS is not enabled (nor recommended) by default, thus PHP
omits this flag during initialization.
I tried then to change the OCI extension code to use this flag by
default using the patch bellow - the problem was solved, apache in
multi-process mode didn't failed anymore on the PHP script.
Patch:
---8<---
diff -Naur php-5.0.3/ext/oci8/oci8.c php-5.0.3-mp/ext/oci8/oci8.c
--- php-5.0.3/ext/oci8/oci8.c 2004-11-22 22:46:49.000000000 +0100
+++ php-5.0.3-mp/ext/oci8/oci8.c 2005-01-11 14:20:56.802128000 +0100
@@ -622,11 +622,7 @@
#endif
-#ifdef ZTS
#define PHP_OCI_INIT_MODE PHP_OCI_INIT_MODE_TMP | OCI_THREADED
-#else
-#define PHP_OCI_INIT_MODE PHP_OCI_INIT_MODE_TMP
-#endif
mutex_alloc(mx_lock);
---8<---
It seems that to allow to run PHP OCI extension in apache multi-process
mode it is required to initialize the OCI library with OCI_THREADED
flag, otherwise PHP may cause apache to crash.
There are several other unresolved bugreports in bugs.php.net database
related to this combination (solaris + apache + php-4.x/php-5.x) and
crash in _oci_close_session().
The default initialization with OCI_THREADED should not hurt any
functionality and it seems it solves the problem.
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=31533&edit=1
