php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #36607 default_prefetch problem w/ dbLinks
Submitted: 2006-03-03 20:13 UTC Modified: 2006-03-20 01:00 UTC
Votes:4
Avg. Score:4.5 ± 0.9
Reproduced:4 of 4 (100.0%)
Same Version:2 (50.0%)
Same OS:3 (75.0%)
From: jreed at myers dot com Assigned:
Status: No Feedback Package: OCI8 related
PHP Version: 5.1.2 OS: Linux - 386
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: jreed at myers dot com
New email:
PHP Version: OS:

 

 [2006-03-03 20:13 UTC] jreed at myers dot com 
Description:
------------
When oci8.default_prefetch is set to anything but zero, executing a SQL statement that uses a dbLink and only returns a single row causes Apache to seg fault.  If oci8.default_prefetch is set to zero then it works fine.  This problem only seems to occur if you do a SELECT *.  If you identify the exact columns to select then it works fine.  Also, the same statement works fine, even with SELECT *, if you connect to the database directly.  It only fails if accessing through a dbLink.

Reproduce code:
---------------
$sql = "
select
    *
from
    my_schema.my_table@my_db_link
where
    table_id = $some_id
";
$stmt = ociparse($conn, $sql);
ociexecute($stmt, OCI_DEFAULT);
ocifetchinto($stmt, $row, OCI_ASSOC);
ocifreestatement($stmt);


Expected result:
----------------
$row is a populated associative array with all the columns from the table row requested.

Actual result:
--------------
Apache seg faults immediately after the ociexecute() call.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-03-05 08:39 UTC] tony2001@php.net 
Please try using this CVS snapshot:

  http://snaps.php.net/php5.1-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.1-win32-latest.zip

Please provide the backtrace if you're still able to reproduce it with the latest snapshot.
 [2006-03-07 00:37 UTC] jreed at myers dot com 
Using latest PHP snapshot php5.1-200603062130 w/ OCI8 module $Revision: 1.269.2.10 $

Apache v2.2.0
Oracle Instant Client v10.2

SQL query still results in seg fault.  Here is the backtrace:

Detaching after fork from child process 17169.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -150749056 (LWP 17160)] 0x052373da in ttcfopr () from /usr/local/instantclient/lib/libclntsh.so.10.1
(gdb)
(gdb) bt
#0  0x052373da in ttcfopr () from /usr/local/instantclient/lib/libclntsh.so.10.1
#1  0x0522e698 in ttcdrv () from /usr/local/instantclient/lib/libclntsh.so.10.1
#2  0x05114ec5 in nioqwa () from /usr/local/instantclient/lib/libclntsh.so.10.1
#3  0x04f82d97 in upirtrc () from /usr/local/instantclient/lib/libclntsh.so.10.1
#4  0x04ef8a36 in kpurcsc () from /usr/local/instantclient/lib/libclntsh.so.10.1
#5  0x04eae07b in kpuexecv8 () from /usr/local/instantclient/lib/libclntsh.so.10.1
#6  0x04eb040a in kpuexec () from /usr/local/instantclient/lib/libclntsh.so.10.1
#7  0x04f87902 in OCIStmtExecute () from /usr/local/instantclient/lib/libclntsh.so.10.1
#8  0x002fa205 in php_oci_statement_execute (statement=0x949ca8c, mode=155822076)
    at /root/php5.1-200603062130/ext/oci8/oci8_statement.c:321
#9  0x002ff712 in zif_oci_execute (ht=2, return_value=0x957fccc, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0)
    at /root/php5.1-200603062130/ext/oci8/oci8_interface.c:1276
#10 0x0120772d in zend_do_fcall_common_helper_SPEC (execute_data=0xfef25690) at zend_vm_execute.h:192
#11 0x004c73ef in get_module () from /usr/local/Zend/lib/Optimizer-2_6_1/php-5.1.x/ZendOptimizer.so
#12 0xfef25690 in ?? ()
#13 0xfef25690 in ?? ()
#14 0x00000001 in ?? ()
#15 0x09319308 in ?? ()
#16 0xfef255d4 in ?? ()
#17 0x00000000 in ?? ()
 [2006-03-07 01:02 UTC] bjori@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 for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

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.

"Always disable any Zend or other 3rd party extensions (Turck MMCache, ionCube loader, Xdebug, APC) before submitting a *PHP* bug."
 [2006-03-07 01:05 UTC] jreed at myers dot com 
Backtrace already provided.
 [2006-03-07 08:38 UTC] tony2001@php.net 
Disable all zend_extensions and try again.
 [2006-03-07 18:52 UTC] jreed at myers dot com 
Same result with no Zend extensions.  I am the only one with Zend extensions installed.  Others who never installed Zend have the same problem.
 [2006-03-07 20:42 UTC] jreed at myers dot com 
Here's the backtrace with all Zend extensions removed/turned off:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -150626176 (LWP 20044)] 0x020683da in ttcfopr () from /usr/local/instantclient/lib/libclntsh.so.10.1
(gdb) bt
#0  0x020683da in ttcfopr () from /usr/local/instantclient/lib/libclntsh.so.10.1
#1  0x0205f698 in ttcdrv () from /usr/local/instantclient/lib/libclntsh.so.10.1
#2  0x01f45ec5 in nioqwa () from /usr/local/instantclient/lib/libclntsh.so.10.1
#3  0x01db3d97 in upirtrc () from /usr/local/instantclient/lib/libclntsh.so.10.1
#4  0x01d29a36 in kpurcsc () from /usr/local/instantclient/lib/libclntsh.so.10.1
#5  0x01cdf07b in kpuexecv8 () from /usr/local/instantclient/lib/libclntsh.so.10.1
#6  0x01ce140a in kpuexec () from /usr/local/instantclient/lib/libclntsh.so.10.1
#7  0x01db8902 in OCIStmtExecute () from /usr/local/instantclient/lib/libclntsh.so.10.1
#8  0x00476205 in php_oci_statement_execute (statement=0x862fa5c, mode=140695500)
    at /root/php5.1-200603062130/ext/oci8/oci8_statement.c:321
#9  0x0047b712 in zif_oci_execute (ht=2, return_value=0x871c724, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0)
    at /root/php5.1-200603062130/ext/oci8/oci8_interface.c:1276
#10 0x011f472d in zend_do_fcall_common_helper_SPEC (execute_data=0xfef46920) at zend_vm_execute.h:192
#11 0x011f40a1 in execute (op_array=0x8606cd8) at zend_vm_execute.h:92
#12 0x011f452f in zend_do_fcall_common_helper_SPEC (execute_data=0xfef4df30) at zend_vm_execute.h:226
#13 0x011f40a1 in execute (op_array=0x85be084) at zend_vm_execute.h:92
#14 0x011df7be in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /root/php-5.1.2/Zend/zend.c:1101
#15 0x011aef24 in php_execute_script (primary_file=0xfef50270) at /root/php-5.1.2/main/main.c:1720
#16 0x01236f08 in php_handler (r=0x85ab410) at /root/php-5.1.2/sapi/apache2handler/sapi_apache2.c:584
#17 0x080765b2 in ap_run_handler (r=0x85ab410) at config.c:157
#18 0x08076ac6 in ap_invoke_handler (r=0x85ab410) at config.c:371
#19 0x08092eff in ap_process_request (r=0x85ab410) at http_request.c:258 #20 0x08090fd1 in ap_process_http_connection (c=0x85a5238) at http_core.c:171
#21 0x0807bb02 in ap_run_process_connection (c=0x85a5238) at connection.c:43
#22 0x080a09f7 in child_main (child_num_arg=0) at prefork.c:640
#23 0x080a0af0 in make_child (s=0x83d1fd0, slot=0) at prefork.c:680
#24 0x080a1531 in ap_mpm_run (_pconf=0x83cd0a8, plog=0x8409198, s=0x83d1fd0) at prefork.c:956
#25 0x08066f5c in main (argc=2, argv=0xfef50634) at main.c:712
 [2006-03-08 07:37 UTC] cjbj at hotmail dot com 
That stack trace is pretty deep in Oracle.  In case this problem needs to be reported to them, what is the version
of the Oracle client libraries that PHP is linked with?  What is the Oracle server version?  How are you creating the DB link?
 [2006-03-08 19:05 UTC] jreed at myers dot com 
As stated previously, Oracle Instant Client v10.2.  Server version is 10.2 with dbLink v10.2 which links to a database v8i.

To create the dblink:
create database link linkname connect to username identified by password using databasename;
 [2006-03-10 05:57 UTC] cjbj at hotmail dot com 
I'd contact Oracle Support about this.   Give them the stack trace.  There seems to be a couple of recent 10.2 reports to Oracle with a similar trace.
 [2006-03-10 18:39 UTC] jreed at myers dot com 
The same query works just fine when I run it within SQL*Plus.  And the query works fine without the oci8.default_prefetch turned on.  So this clearly leads to a problem with the PHP OCI8 driver.
 [2006-03-12 09:04 UTC] tony2001@php.net 
>The same query works just fine when I run it within SQL*Plus.
Sure. Because you don't use prefetching.

>So this clearly leads to a problem with the PHP OCI8 driver.
Please follow the advice from cjbj at hotmail dot com.
 [2006-03-20 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".
 [2006-05-12 13:15 UTC] php at contact dot ady dot ro 
Try applying a patch for Oracle Bug:3396162
 [2010-06-28 20:23 UTC] jonswaff at gmail dot com 
I encountered the same issue using OCI8 version 1.2.5 with PHP version 5.2.13. Changing oci8.default_prefetch to zero did fix the problem but was not desirable. I upgraded to OCI8 version 1.4.1 and all was solved. I know this issue is quite old, but am commenting anyway in hopes that I save someone some time troubleshooting.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Dec 26 14:01:30 2024 UTC