php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #31533 crash in _oci_close_session
Submitted: 2005-01-13 10:33 UTC Modified: 2005-09-08 17:23 UTC
Votes:5
Avg. Score:4.2 ± 1.0
Reproduced:5 of 5 (100.0%)
Same Version:4 (80.0%)
Same OS:4 (80.0%)
From: martin dot pala at oskar dot cz Assigned: tony2001 (profile)
Status: Closed Package: OCI8 related
PHP Version: 5.0.x OS: Solaris + Linux
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: martin dot pala at oskar dot cz
New email:
PHP Version: OS:

 

 [2005-01-13 10:33 UTC] 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.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-01-14 21:27 UTC] tony2001@php.net
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-18 10:19 UTC] 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-18 11:32 UTC] tony2001@php.net
Ok, marking the report as waiting for feedback then.
 [2005-01-26 16:09 UTC] martin dot pala at oskar dot cz
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.
 [2005-04-06 10:36 UTC] martin dot pala at oskar dot cz
We have moved our application to linux (Redhat EL3), it is more stable then on solaris, however the problem persist.

Current configuration is PHP-5.0.4 + Apache-2.0.46 + OCI instant client 10.1.0.3.

We now see the same crashes in OCI as on solaris. It happens when the child wants to gracefuly exit in _oci_close_session:

--8<--
(gdb) bt
#0  0x015898f0 in kpufhndl0 () from /usr/lib/oracle/10.1.0.3/client/lib/libclntsh.so.10.1
#0  0x015898f0 in kpufhndl0 () from /usr/lib/oracle/10.1.0.3/client/lib/libclntsh.so.10.1
#1  0x015898a8 in kpufhndl () from /usr/lib/oracle/10.1.0.3/client/lib/libclntsh.so.10.1
#2  0x015fa043 in OCIHandleFree () from /usr/lib/oracle/10.1.0.3/client/lib/libclntsh.so.10.1
#3  0x0111c83a in _oci_close_session (session=0x1f78510) at /usr/src/redhat/BUILD/php-5.0.4/ext/oci8/oci8.c:3007
#4  0x011f54ff in list_entry_destructor (ptr=0xb6a0bc24) at /usr/src/redhat/BUILD/php-5.0.4/Zend/zend_list.c:178
#5  0x011f4248 in zend_hash_apply_deleter (ht=0xb69fe404, p=0xb69fe434)
    at /usr/src/redhat/BUILD/php-5.0.4/Zend/zend_hash.c:574
#6  0x011f42ec in zend_hash_graceful_reverse_destroy (ht=0x1407754) at /usr/src/redhat/BUILD/php-5.0.4/Zend/zend_hash.c:640
#7  0x011e3fd6 in shutdown_executor () at /usr/src/redhat/BUILD/php-5.0.4/Zend/zend_execute_API.c:283
#8  0x011edaf4 in zend_deactivate () at /usr/src/redhat/BUILD/php-5.0.4/Zend/zend.c:817
#9  0x011b8b66 in php_request_shutdown (dummy=0x0) at /usr/src/redhat/BUILD/php-5.0.4/main/main.c:1216
#10 0x01216fc7 in php_handler (r=0xb72eb030) at /usr/src/redhat/BUILD/php-5.0.4/sapi/apache2handler/sapi_apache2.c:590
#11 0x080685c5 in ap_run_handler ()
#12 0x08068bdf in ap_invoke_handler ()
#13 0x08065266 in ap_process_request ()
#14 0x080608bc in _start ()
#15 0xb72eb030 in ?? ()
#16 0x00000004 in ?? ()
#17 0xb72eb030 in ?? ()
#18 0x080722dc in ap_run_pre_connection ()
#19 0x08072195 in ap_run_process_connection ()
#20 0x08066ae1 in ap_graceful_stop_signalled ()
#21 0x08066c34 in ap_graceful_stop_signalled ()
#22 0x08066ed9 in ap_graceful_stop_signalled ()
#23 0x08067570 in ap_mpm_run ()
#24 0x0806da4f in main ()
--8<--

It seems that the session context was damaged:
--8<--
(gdb) frame 3
#3  0x0111c83a in _oci_close_session (session=0x1f78510) at /usr/src/redhat/BUILD/php-5.0.4/ext/oci8/oci8.c:3007
3007                    );
(gdb) print session
$14 = (oci_session *) 0x1f78510
(gdb) print *session
$15 = {num = 11990016, persistent = 0 '\0', is_open = 0 '\0', exclusive = 0 '\0', thread = 0 '\0', sessions_list = 0x0,
  server = 0x1a6eac6, pSession = 0x1882cae, pEnv = 0x1d40c08, charsetId = 51142}
(gdb) print *session->server
$16 = {num = -2081649835, persistent = 2106149100, is_open = -864712248,
  dbname = 0x8b08458b <Address 0x8b08458b out of bounds>, pServer = 0x4d8b0c55}
--8<--

=> it seems that the problem affects all systems, the session context gets somehow corrupted.

Martin
 [2005-04-06 16:06 UTC] martin dot pala at oskar dot cz
... finaly we've found the problem :)

We were using the same tnsname to create two connections (to two different schemes on the same DB) - the second initialization damaged the oci session context (the physical connection is only one and is shared).

Maybe php oci module should not allow to rewrite the existing oci session context ...


Possible workaround is:

- either use different tnsname (alias) for each connection - it will create several physical connections (one per tnsname)

- or consolidate the connections (don't use multiple connections to the same tnsname)
 [2005-04-06 16:17 UTC] martin dot pala at oskar dot cz
... i forgot to underline the fact that it is related to persistent connections only (as it is possible to see it from older comments ;)

"Classical" connections are not affected by this issue.
 [2005-06-20 12:11 UTC] martin dot pala at oskar dot cz
Thanks for hint :)

Unfortunately, the servers are in production already and we can't use development snapshot anymore ... we will wait for php-5.0.5 and test it then.

Thanks,
Martin
 [2005-06-21 18:02 UTC] sniper@php.net
Give feedback when you have feedback. (Something else than 'we can test..'. And next PHP 5 version is most likely 5.1 and there will not be 5.0.5..

 [2005-07-05 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2005-09-08 17:23 UTC] tony2001@php.net
The bug has been fixed in OCI8 v.1.1, which is available in CVS HEAD and PECL (use `pear install oci8-beta` to install it).
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 06:01:29 2024 UTC