Bug #71708 [Asn]: Oracle queries using oci_fetch_all causes Core Dumps

Edit report at https://bugs.php.net/bug.php?id=71708&edit=1 ID: 71708 User updated by: jodybrabec at gmail dot com Reported by: jodybrabec at gmail dot com Summary: Oracle queries using oci_fetch_all causes Core Dumps Status: Assigned Type: Bug Package: OCI8 related Operating System: RHEL 6.7 PHP Version: 7.0.4 Assigned To: sixd Block user comment: N Private report: N New Comment: 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_id5Se3incident_pkEZ: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 ================================================================== Previous Comments: ------------------------------------------------------------------------ [2016-03-08 00:49:37] sixd@php.net Likely a dup of 71600. Answers to the questions would help me reproduce it. ------------------------------------------------------------------------ [2016-03-05 02:04:53] 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-04 23:27:50] 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-04 00:31:02] 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-03 20:21:08] 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' ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=71708&edit=1