php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #29864 CLI PHP crash after successful script completion when querying Oracle 9 DB CLOB
Submitted: 2004-08-27 12:40 UTC Modified: 2005-02-22 01:00 UTC
Votes:2
Avg. Score:4.5 ± 0.5
Reproduced:2 of 2 (100.0%)
Same Version:2 (100.0%)
Same OS:2 (100.0%)
From: Volker dot Weinberger at pharma dot novartis dot com Assigned:
Status: No Feedback Package: OCI8 related
PHP Version: 5.0.1 OS: Solaris 5.8
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: Volker dot Weinberger at pharma dot novartis dot com
New email:
PHP Version: OS:

 

 [2004-08-27 12:40 UTC] Volker dot Weinberger at pharma dot novartis dot com
Description:
------------
PHP CLI script consistently crashes with 5.0.1 *after* successful completion, i.e. the script executes successfully right to the end ("just before the end" line is printed in sample script below). Then, after a short delay, a bus error is produced (core dump).

The same scripts (as well as the original script, sample script is shortened) work fine with CLI PHP 4.3.6 .

The issue is tracked down to the d.seq field in the Oracle query, which is a CLOB 4000 field. The script does not crash when this field is omitted from the query.

PEAR DB is used for Oracle connection. PEAR DB version: 
//
// $Id: DB.php,v 1.59 2004/07/08 21:15:11 danielc Exp $
//


Reproduce code:
---------------
#!.../php501
<?php
require_once('DB.php');

$dbh = DB::connect("oci8://...");
if (!$dbh) {
        die("ERROR:Cannot connect to BCH1!");
}

$sql =  " SELECT d.seq " .
        " FROM sqbox.seqmandata d WHERE d.nvs_id = 'NVS00002050'" ;

$sth=$dbh->query($sql);
if(DB::isError($sth)){
   die ($sth->getMessage());
}

print "just before the end\n";
?>

Expected result:
----------------
No core dump.

Actual result:
--------------
Script produces full correct results, but core dumps right at the end.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-08-27 13:17 UTC] derick@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
 [2004-08-27 15:47 UTC] Volker dot Weinberger at pharma dot novartis dot com
Backtrace attempt:

unfortunately I'm not able to compile with --enable-debug (filed as a separate bug report).

Backtrace info without --enable-debug:

(gdb) bt
#0  0x7edbe1ac in kpughndl0 ()from /u01/home/oracle/product/9.2.0/lib32/libclntsh.so.9.0
#1  0xbcd5c in _oci_close_session ()
#2  0x2597ec in list_entry_destructor ()
#3  0x256fc4 in zend_hash_del_key_or_index ()
#4  0x259480 in _zend_list_delete ()
#5  0xb8ea0 in _oci_conn_list_dtor ()
#6  0x2597ec in list_entry_destructor ()
#7  0x2572a4 in zend_hash_apply_deleter ()
#8  0x25746c in zend_hash_graceful_reverse_destroy ()
#9  0x23d1cc in shutdown_executor ()
#10 0x24ec38 in zend_deactivate ()
#11 0x1eda8c in php_request_shutdown ()
#12 0x28a984 in main ()


(gdb) frame 2
#2  0x2597ec in list_entry_destructor ()
<tor_globals.function_state_ptr->function)->common.function_name             
Attempt to extract a component of a value that is not a structure.

(gdb) frame 1
#1  0xbcd5c in _oci_close_session ()
<function_state_ptr->function)->common.function_name
Attempt to extract a component of a value that is not a structure.
<tor_globals.function_state_ptr->function)->common.function_name
 [2005-01-18 14:05 UTC] Volker dot Weinberger at pharma dot novartis dot com
I've managed to get --enable-debug compiled in with a recent CVS version of PHP: php5-200501180930 .  The same error still occurs.

Following instructions for a gdb backtrace I get:

 gdb ./php ./core
GNU gdb 5.0
...
(gdb) bt
#0  0x34e204 in ZEND_RETURN_SPEC_CV_HANDLER ()
#1  0x31946c in execute ()
#2  0x319948 in zend_do_fcall_common_helper_SPEC ()
#3  0x319d84 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER ()
#4  0x31946c in execute ()
#5  0x319948 in zend_do_fcall_common_helper_SPEC ()
#6  0x319d84 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER ()
#7  0x31946c in execute ()
#8  0x319948 in zend_do_fcall_common_helper_SPEC ()
#9  0x319d84 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER ()
#10 0x31946c in execute ()
#11 0x2db78c in zend_execute_scripts ()
#12 0x265050 in php_execute_script ()
#13 0x370018 in main ()
(gdb) frame 1
#1  0x31946c in execute ()
(gdb) print (char *)(executor_globals.function_state_ptr->function)->common.function_name
Attempt to extract a component of a value that is not a structure.
(gdb) 

Since PHP wasn't compiled with GCC, but with Solaris CC, using GDB might not give the expected result.

Using SUN dbx instead:
dbx ./php ./cor
...
detected a multithreaded program
t@1 (l@1) terminated by signal BUS (invalid address alignment)
Current function is ZEND_RETURN_SPEC_CV_HANDLER (optimized)
17699                                   || (opline->extended_value == ZEND_RETURNS_FUNCTION && !EX_T(opline->op1.u.var).var.fcall_returned_reference)) {

(/opt/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) where
current thread: t@1
=>[1] ZEND_RETURN_SPEC_CV_HANDLER(execute_data = ???) (optimized), at 0x34e204 (line ~17699) in "zend_vm_execute.h"
  [2] execute(op_array = ???) (optimized), at 0x319464 (line ~78) in "zend_vm_execute.h"
  [3] zend_do_fcall_common_helper_SPEC(execute_data = ???) (optimized), at 0x319940 (line ~204) in "zend_vm_execute.h"
  [4] ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER(execute_data = ???) (optimized), at 0x319d7c (line ~288) in "zend_vm_execute.h"
  [5] execute(op_array = ???) (optimized), at 0x319464 (line ~78) in "zend_vm_execute.h"
  [6] zend_do_fcall_common_helper_SPEC(execute_data = ???) (optimized), at 0x319940 (line ~204) in "zend_vm_execute.h"
  [7] ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER(execute_data = ???) (optimized), at 0x319d7c (line ~288) in "zend_vm_execute.h"
  [8] execute(op_array = ???) (optimized), at 0x319464 (line ~78) in "zend_vm_execute.h"
  [9] zend_do_fcall_common_helper_SPEC(execute_data = ???) (optimized), at 0x319940 (line ~204) in "zend_vm_execute.h"
  [10] ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER(execute_data = ???) (optimized), at 0x319d7c (line ~288) in "zend_vm_execute.h"
  [11] execute(op_array = ???) (optimized), at 0x319464 (line ~78) in "zend_vm_execute.h"
  [12] zend_execute_scripts(type = ???, retval = ???, file_count = ???, ...) (optimized), at 0x2db784 (line ~1058) in "zend.c"
  [13] php_execute_script(primary_file = ???) (optimized), at 0x265048 (line ~1636) in "main.c"
  [14] main(argc = ???, argv = ???) (optimized), at 0x370010 (line ~944) in "php_cli.c"

>frame 2
Current function is execute (optimized)
   78                   if (EX(opline)->handler(&execute_data TSRMLS_CC) > 0) {

(char *) executor_globals.function_state_ptr->function->common.function_name = 0xac55c0 "raiseError"
 [2005-02-14 10:41 UTC] tony2001@php.net
Please, see bug #31533 and try the patch supplied there.
Seems that werdie Solarises are broken (or Oracle for Solaris is).
Also I should note that your last bt is very odd. 
I've never seen such senseless backtraces before =)
 [2005-02-22 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".
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Dec 21 18:01:29 2024 UTC