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
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: jodybrabec at gmail dot com
New email:
PHP Version: OS:

 

 [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

Pull Requests

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-2024 The PHP Group
All rights reserved.
Last updated: Thu Nov 21 15:01:30 2024 UTC