php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #71708 Oracle queries using oci_fetch_all causes Core Dumps
Submitted: 2016-03-03 20:21 UTC Modified: 2017-09-18 22:29 UTC
Votes:5
Avg. Score:5.0 ± 0.0
Reproduced:4 of 4 (100.0%)
Same Version:4 (100.0%)
Same OS:0 (0.0%)
From: jodybrabec at gmail dot com Assigned: sixd (profile)
Status: Duplicate Package: OCI8 related
PHP Version: 7.0.4 OS: RHEL 6.7
Private report: No CVE-ID: None
 [2016-03-03 20:21 UTC] jodybrabec at gmail dot com
Description:
------------
Oracle queries using oci_fetch_all causes Core Dumps sometimes if more than one record result set.

My setup: oracle-instantclient12.1-basic, OCI8 2.1.0, PHP 70, php70-php-cli (7.0.4-1.el6.remi - 2016-03-02), Red Hat EL 6.7, HTTPD 24

Observations on oci_fetch_all queries:
	1. If the query return set contains only one record, no problems.
	2. For more than one records return: Sometimes causes core dump (browser Error 500 Internal server error). 
		a. If total return bytes is large, core dump probability increases (possible cap on rows * bytes per record per clumn cell)
		b. Or sometimes error on only 2+ records - yet removing various columns reduces error probability.
		c. Queries with "joins" increase error probability.


Test script:
---------------
// Cor dumps on many random queries - see Observations above
$statement= oci_parse($connID, $query);
oci_execute($statement)
// ================= BAD, CORE DUMP:
$numRows = oci_fetch_all($statement, $results);


Expected result:
----------------
yum php70-php-cli (remi) was updated last night, but still no work.

POSSIBLE WORKAROUND:

// *********** (THIS DOES NOT WORK RIGHT NOW!!!!) **********
$allCols = oci_num_fields($st);
$colNames = array();
for ($i_c = 1; $i_c <= $allCols; $i_c++) {
	$aColName  = oci_field_name($statement, $i_c);
	$colNames[] = $aColName;
}
$numRows = 0;
while (($row = oci_fetch_array($statement, OCI_BOTH)) != false) {
	$numRows++;
	foreach ($colNames as $i_c=>$aColName)
		$results[$aColName][] = $row[$aColName];
}


Actual result:
--------------
//~~~~~~~~~~~~~~~~~~~ CORE DUMP 
#> tail /var/log/messages
Mar  2 22:17:17 node6 abrtd: Directory 'ccpp-2016-03-02-22:17:17-32306' creation detected
Mar  2 22:17:17 node6 abrt[32307]: Saved core dump of pid 32306 (/opt/remi/php70/root/usr/bin/php-cgi) to /var/spool/abrt/ccpp-2016-03-02-22:17:17-32306 (11370496 bytes)
Mar  2 22:17:17 node6 abrtd: Package 'php70-php-cli' isn't signed with proper key
Mar  2 22:17:17 node6 abrtd: 'post-create' on '/var/spool/abrt/ccpp-2016-03-02-22:17:17-32306' exited with 1
Mar  2 22:17:17 node6 abrtd: Deleting problem directory '/var/spool/abrt/ccpp-2016-03-02-22:17:17-32306'



Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2016-03-04 00:31 UTC] sixd@php.net
-Status: Open +Status: Feedback -Assigned To: +Assigned To: sixd
 [2016-03-04 00:31 UTC] sixd@php.net
What query/queries crash?
Can you post some DDL to create a table that is known to crash - what data types are you using?
Can you create a backtrace?
Does PHP 5.6 / OCI8 2.0 also crash?
 [2016-03-04 23:27 UTC] jodybrabec at gmail dot com
-Status: Feedback +Status: Assigned
 [2016-03-04 23:27 UTC] jodybrabec at gmail dot com
function my_oci_fetch_all($statement, &$output)
{
	/***
	* Workaround for oci_fetch_all - very similar to http://php.net/manual/en/function.oci-fetch-all.php
	* Uses oci_fetch_array iteratively (instead of oci_fetch_all which currently has problems whith 2+ query result set)
	* Fills &$output.  Returns the number of rows in &$output.
	* ##### Needs More Testing - let us know if problems #####
	* 2016-03-04 jodybrabec@gmail.com
	 */
	$rows = 0;
	$allCols = oci_num_fields($statement);
	$colNames = array();
	for ($i_c = 1; $i_c <= $allCols; $i_c++) {
		$aColName  = oci_field_name($statement, $i_c);
		$colNames[$aColName] = $aColName; // force unique via key
	}
	while (($row = oci_fetch_array($statement, OCI_RETURN_LOBS)) != false)
	{
		$rows++;
		foreach ($colNames as $i_c=>$aColName)
			$output[$aColName][] = $row[$aColName];
	}
	return $rows;
}
 [2016-03-05 02:04 UTC] sixd@php.net
-Status: Assigned +Status: Feedback
 [2016-03-05 02:04 UTC] sixd@php.net
Answers to questions asked on 2016-03-04 00:31 UTC would help.  The PHP code snippet workaround doesn't help.
 [2016-03-08 00:49 UTC] sixd@php.net
-Status: Feedback +Status: Open
 [2016-03-08 00:49 UTC] sixd@php.net
Likely a dup of 71600.

Answers to the questions would help me reproduce it.
 [2016-03-09 22:02 UTC] jodybrabec at gmail dot com
Hi sorry for delay. I have been digging deep - still learning.
I'll give quicker response time next time.

Here is some DDL and oracle trace:

===================================================

CREATE TABLE TESTB ( REQUEST_ID NUMBER(10), REQUEST_YR VARCHAR2(2), REQUEST_TYPE NUMBER(10), DEADLINE DATE, SUBMITTED DATE, STATUSID NUMBER(1), LOTID_NUM NUMBER(10), ASSIGNED_EID VARCHAR2(15), REQUESTED_EID VARCHAR2(15) );
insert into TESTB (REQUEST_ID, REQUEST_YR, REQUEST_TYPE, DEADLINE, SUBMITTED, STATUSID, LOTID_NUM, ASSIGNED_EID, REQUESTED_EID) values (1, '15', 93, TIMESTAMP '2015-06-20 00:00:00', TIMESTAMP '2015-06-11 05:40:18', 3, null, '06008725', '10207642');
insert into TESTB (REQUEST_ID, REQUEST_YR, REQUEST_TYPE, DEADLINE, SUBMITTED, STATUSID, LOTID_NUM, ASSIGNED_EID, REQUESTED_EID) values (2, '15', 52, TIMESTAMP '2015-06-12 00:00:00', TIMESTAMP '2015-06-10 17:10:27', 3, null, '22053128', '01833315');
insert into TESTB (REQUEST_ID, REQUEST_YR, REQUEST_TYPE, DEADLINE, SUBMITTED, STATUSID, LOTID_NUM, ASSIGNED_EID, REQUESTED_EID) values (3, '15', 45, TIMESTAMP '2015-08-17 00:00:00', TIMESTAMP '2015-06-11 06:31:18', 3, null, '01641215', '14403633');

===================================================
 FILE: test.php:
<?php
// Test oci_fetch_all - The third $query, BAD:

/////// GOOD QUERY - no errors
$query = "select REQUEST_ID, REQUEST_YR, REQUEST_TYPE, DEADLINE, SUBMITTED, STATUSID, LOTID_NUM, ASSIGNED_EID, REQUESTED_EID from PARKING.TESTB where REQUEST_ID = 1";
/////// GOOD QUERY - no errors
$query = "select REQUEST_ID, REQUEST_YR, REQUEST_TYPE, DEADLINE, SUBMITTED, STATUSID, LOTID_NUM, ASSIGNED_EID                from PARKING.TESTB where REQUEST_ID >= 1";
/////// BAD QUERY - all hell barks loose!
$query = "select REQUEST_ID, REQUEST_YR, REQUEST_TYPE, DEADLINE, SUBMITTED, STATUSID, LOTID_NUM, ASSIGNED_EID, REQUESTED_EID from PARKING.TESTB where REQUEST_ID >= 1";

$pas = 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX';
$identifier = "(DESCRIPTION =	(ADDRESS_LIST = (ADDRESS = (PROTOCOL=TCP) (HOST=128.196.6.211) (PORT=1521)) ) (CONNECT_DATA = (SERVICE_NAME=node11o.node11.pts.arizona.edu) ) )";
$conn  = oci_connect('parking', $pas, $identifier);

$stid  = oci_parse($conn, $query);
oci_execute($stid);

echo "<br>-------------- BEGIN - oci_fetch_all testing... <br>";
$nrows = oci_fetch_all($stid, $res);
echo "<br>-------- END - oci_fetch_all worked (rows: $nrows<br>";
?>

===============================================================
  BEGIN messages and Oracle trace - for "BAD QUERY" execution above
===============================================================

tail -60 /var/log/messages
Mar  9 13:45:16 node6 abrtd: Directory 'ccpp-2016-03-09-13:45:16-46893' creation detected
Mar  9 13:45:16 node6 abrt[46897]: Saved core dump of pid 46893 (/opt/remi/php70/root/usr/bin/php-cgi) to /var/spool/abrt/ccpp-2016-03-09-13:45:16-46893 (11362304 bytes)
Mar  9 13:45:16 node6 abrtd: Package 'php70-php-cli' isn't signed with proper key
Mar  9 13:45:16 node6 abrtd: 'post-create' on '/var/spool/abrt/ccpp-2016-03-09-13:45:16-46893' exited with 1
Mar  9 13:45:16 node6 abrtd: Deleting problem directory '/var/spool/abrt/ccpp-2016-03-09-13:45:16-46893'

===================================================
 FILE /var/log/audit/audit.log, where time = 145755631 (Wed Aug 14 16:40:31 MST 1974):
type=ANOM_ABEND msg=audit(1457556316.646:4526): auid=0 uid=48 gid=48 ses=1 subj=unconfined_u:system_r:httpd_sys_script_t:s0 pid=46893 comm="php-cgi" sig=11

====================================================

tail /var/tmp/oradiag_apache/diag/clients/user_apache/host_2873318587_82/trace/sqlnet.log:
Wed Mar 09 13:45:16 2016
Errors in file /var/tmp/oradiag_apache/diag/clients/user_apache/host_2873318587_82/trace/ora_46893_139913458235360.trc  (incident=11321):
oci-24550 [11] [[si_signo=11] [si_errno=0] [si_code=1] [si_int=0] [si_ptr=(nil)] [si_addr=0x8]] [] [] [] [] [] [] [] [] [] []
Incident details in: /var/tmp/oradiag_apache/diag/clients/user_apache/host_2873318587_82/incident/incdir_11321/ora_46893_139913458235360_i11321.trc

-----------------------------------------------------

Trace file /var/tmp/oradiag_apache/diag/clients/user_apache/host_2873318587_82/trace/ora_46893_139913458235360.trc
DDE: Flood control is not active
Incident 11321 created, dump file: /var/tmp/oradiag_apache/diag/clients/user_apache/host_2873318587_82/incident/incdir_11321/ora_46893_139913458235360_i11321.trc
oci-24550 [11] [[si_signo=11] [si_errno=0] [si_code=1] [si_int=0] [si_ptr=(nil)] [si_addr=0x8]] [] [] [] [] [] [] [] [] [] []

---------------

Dump file /var/tmp/oradiag_apache/diag/clients/user_apache/host_2873318587_82/incident/incdir_11321/ora_46893_139913458235360_i11321.trc
[TOC00000]
Jump to table of contents
Dump continued from file: /var/tmp/oradiag_apache/diag/clients/user_apache/host_2873318587_82/trace/ora_46893_139913458235360.trc
[TOC00001]
oci-24550 [11] [[si_signo=11] [si_errno=0] [si_code=1] [si_int=0] [si_ptr=(nil)] [si_addr=0x8]] [] [] [] [] [] [] [] [] [] []
[TOC00001-END]
[TOC00002]
========= Dump for incident 11321 (oci 24550 [11]) ========
Tracing is in restricted mode!
[TOC00003]
----- Short Call Stack Trace -----
dbgexPhaseII()+878<-dbgexProcessError()+2539<-dbgeExecuteForError()+110<-dbgePostErrorDirect()+2230<-kpeDbgSignalHandler()+302<-skgesig_sigactionHandler()+229<-__sighandler()<-_zend_hash_index_update()+21<-zif_oci_fetch_all()+1406<-00007F4023C5C040<-FFFFFFFF00001C07[TO$
[TOC00004]
----- START Event Driven Actions Dump ----
---- END Event Driven Actions Dump ----
[TOC00004-END]
[TOC00005]
----- START DDE Actions Dump -----
Executing SYNC actions
Executing ASYNC actions
----- END DDE Actions Dump (total 0 csec) -----
[TOC00005-END]
End of Incident Dump
[TOC00002-END]
TOC00000 - Table of contents
TOC00001 - Error Stack
TOC00002 - Dump for incident 11321 (oci 24550 [11])
| TOC00003 - Short Call Stack Trace
| TOC00004 - START Event Driven Actions Dump
| TOC00005 - START DDE Actions Dump
End of TOC

-------------------------------------------------------

 File: /var/tmp/oradiag_apache/diag/clients/user_apache/host_2873318587_82/trace/ora_46893_139913458235360.trm:

@3|3|L9bHBAAq1"46893_139913458235360|host_2873318587_82|1|1|1|1|1|
02kx+N%dbgexProcessError*diag_dde*dbgex.c*QHp1XIrtBBAAq1~
9Lk++x4$a3incident_id`59:dbgrimbid_begin_incdump*dbgrim.c*incident_file*1LD1Zyjk5"
C40y+7$4+1g"
TK0y+3$010N"
EK0y+x$Error Stack*130E"
C40y+7$3-1B"
UK0y+3$030J"

-------------------------------------------------------

 File: /var/tmp/oradiag_apache/diag/clients/user_apache/host_2873318587_82/incident/incdir_11321/ora_46893_139913458235360_i11321.trm:

@3|3|djcHBAAq1"46893_139913458235360|host_2873318587_82|1|1|1|1|9|
02k++R%dbgrimbid_begin_incdump*dbgrim.c*FE1k2QOkcHBAAq1"
C50y+7$e7filename`d1|0:Ee1T"
6M0y+x$Error Stack*33B0I"
C40y+7$3-1V"
UK0y+3$030I"
2Jkx+x2$a3incident_id`5Se3incident_pk`EZ:dbgexProcessError*diag_dde*dbgex.c*incident_dump*1BKQy
80W3+7$dbgexPhaseII*4MV
6I00+x$short_call_stack_dump*1BBZ
MI00+32$03A40
6I00+x$Event Triggered Actions*1VQh
UG00+3$06e
2Ik++x2$dbgerRunActions*dbger.c*DDE Actions*1rJQZ
C00y+3$RN
!0O
QL0y+32$Z3act_exec_duration`1Y:02NmP62"
I2a3+R2$dbgexEndIncident*4MOFL

==================================================================
                          	  END
==================================================================
 [2016-04-12 00:46 UTC] sixd@php.net
-Status: Assigned +Status: Duplicate
 [2016-04-12 00:46 UTC] sixd@php.net
Dup of Bug #71600
 [2017-09-18 17:08 UTC] jodybrabec at gmail dot com
If still having problems with oci_fetch_all, use jody brabec's workaround function here called "my_oci_fetch_all"
 [2017-09-18 22:29 UTC] sixd@php.net
@ jodybrabec I strongly disagree.  If you are still have problems after upgrading to the latest OCI8 extension (check for it on PECL), then log a bug so it can be addressed.
 [2017-09-19 00:12 UTC] jodybrabec at gmail dot com
I strongly agree with you sixd, thank you.
Jody Brabec
 
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Wed Dec 08 18:03:33 2021 UTC