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
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
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 12:01:31 2024 UTC