PHP :: Bug #41069 :: segfault when running a large query over dblink

Bug #41069

segfault when running a large query over dblink

Submitted:

2007-04-12 22:39 UTC

Modified:

2008-03-04 21:51 UTC

Votes:	2
Avg. Score:	5.0 ± 0.0
Reproduced:	0 of 0 (0.0%)

From:

brian dot kao at gateway dot com

Assigned:

Status:

Closed

Package:

OCI8 related

PHP Version:

5.2.1

OS:

linux

Private report:

CVE-ID:

None

View Developer Edit

[2007-04-12 22:39 UTC] brian dot kao at gateway dot com

Description:
------------
Running a large query over dbLink would cause Apache to seg fault

Apache v1.3.37
Oracle Instant Client v10.2


Reproduce code:
---------------
$sql = "select * from table@db_link";
$stmt = ociparse($conn, $sql);
ociexecute($stmt, OCI_DEFAULT);

Expected result:
----------------
ociexecute() would complete without any error

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

Here's the backtrace:

(gdb) bt
#0  0x0143997a in ttcfopr () from /usr/local/instantclient/libclntsh.so.10.1
#1  0x0143d476 in ttcdrv () from /usr/local/instantclient/libclntsh.so.10.1
#2  0x012d2951 in nioqwa () from /usr/local/instantclient/libclntsh.so.10.1
#3  0x010b837e in upirtrc () from /usr/local/instantclient/libclntsh.so.10.1
#4  0x01168129 in kpurcsc () from /usr/local/instantclient/libclntsh.so.10.1
#5  0x011a3f6f in kpuexecv8 () from /usr/local/instantclient/libclntsh.so.10.1
#6  0x011a5b4a in kpuexec () from /usr/local/instantclient/libclntsh.so.10.1
#7  0x010b2246 in OCIStmtExecute () from /usr/local/instantclient/libclntsh.so.10.1
#8  0x0813b898 in php_oci_statement_execute (statement=0xb7b5abb4, mode=32) at /home/eus110532/php-5.2.1/ext/oci8/oci8_statement.c:372
#9  0x08143de5 in zif_oci_execute (ht=2, return_value=0xb7b58b4c, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
    at /home/eus110532/php-5.2.1/ext/oci8/oci8_interface.c:1287
#10 0x0835be35 in zend_do_fcall_common_helper_SPEC (execute_data=0xbff1e380) at zend_vm_execute.h:200
#11 0x08360885 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0xbff1e380) at zend_vm_execute.h:1681
#12 0x0835ba4a in execute (op_array=0xb7b1ff4c) at zend_vm_execute.h:92
#13 0x0835bf6a in zend_do_fcall_common_helper_SPEC (execute_data=0xbff1e6b0) at zend_vm_execute.h:234
#14 0x0835c84b in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbff1e6b0) at zend_vm_execute.h:322
#15 0x0835ba4a in execute (op_array=0xb7b56090) at zend_vm_execute.h:92
#16 0x0835bf6a in zend_do_fcall_common_helper_SPEC (execute_data=0xbff1ed20) at zend_vm_execute.h:234
#17 0x0835c84b in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbff1ed20) at zend_vm_execute.h:322
#18 0x0835ba4a in execute (op_array=0xb7ade6ec) at zend_vm_execute.h:92
#19 0x0835bf6a in zend_do_fcall_common_helper_SPEC (execute_data=0xbff1f0c0) at zend_vm_execute.h:234
#20 0x0835c84b in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbff1f0c0) at zend_vm_execute.h:322
#21 0x0835ba4a in execute (op_array=0xb7adbe70) at zend_vm_execute.h:92
#22 0x0835bf6a in zend_do_fcall_common_helper_SPEC (execute_data=0xbff1f340) at zend_vm_execute.h:234
#23 0x0835c84b in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbff1f340) at zend_vm_execute.h:322
#24 0x0835ba4a in execute (op_array=0xb7adfb5c) at zend_vm_execute.h:92
#25 0x0835bf6a in zend_do_fcall_common_helper_SPEC (execute_data=0xbff1f490) at zend_vm_execute.h:234
#26 0x0835c84b in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbff1f490) at zend_vm_execute.h:322
#27 0x0835ba4a in execute (op_array=0xb7adf2c8) at zend_vm_execute.h:92
#28 0x0835bf6a in zend_do_fcall_common_helper_SPEC (execute_data=0xbff1f6e0) at zend_vm_execute.h:234
#29 0x0835c84b in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbff1f6e0) at zend_vm_execute.h:322
#30 0x0835ba4a in execute (op_array=0xb7ee8808) at zend_vm_execute.h:92
#31 0x0835bf6a in zend_do_fcall_common_helper_SPEC (execute_data=0xbff1f890) at zend_vm_execute.h:234
#32 0x0835c84b in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbff1f890) at zend_vm_execute.h:322
#33 0x0835ba4a in execute (op_array=0xb7edd1dc) at zend_vm_execute.h:92
#34 0x0833c6fa in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/eus110532/php-5.2.1/Zend/zend.c:1135
#35 0x082f5d75 in php_execute_script (primary_file=0xbff21c50) at /home/eus110532/php-5.2.1/main/main.c:1784
#36 0x083a2104 in main (argc=2, argv=0xbff21d24) at /home/eus110532/php-5.2.1/sapi/cli/php_cli.c:1114

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports

[2007-04-13 07:53 UTC] tony2001@php.net

See bug #36607.
PHP doesn't care whether you access the database using dblink or directly, so it's obviously not PHP problem.

[2007-04-13 08:00 UTC] brian dot kao at gateway dot com

could this be a PHP OCI8 driver issue?

If I limit the number of records returned, the query would run without any issue.  This only happens when running a large query over dblink.

What is your recommendation for this issue, going to Oracle support?

[2007-04-13 08:07 UTC] tony2001@php.net

>could this be a PHP OCI8 driver issue?
I'm saying it knows nothing of dblink.

>What is your recommendation for this issue, going to Oracle support?
Yes.

[2007-04-19 21:48 UTC] brian dot kao at gateway dot com

Tony,

Our Oracle DBA tried reporting this issue to Oracle Support, but they came back to us and say this is not an Oracle issue.

Here's the message I've received from our Oracle DBA: 

"Oracle has closed the SR stating that since the database link works with sqlplus that the issue is with PHP which Oracle does not support.  The database does not need a patch since there is no issue with the database link on the Oracle database side."

Are you aware of any workaround for this issue?

[2007-04-20 07:13 UTC] tony2001@php.net

>Oracle has closed the SR stating that since the database link works
>with sqlplus that the issue is with PHP which Oracle does not support.

Are you sure SQLPlus uses the same client library?

>The database does not need a patch since there is no issue with the
>database link on the Oracle database side

I'm aware of similar issues, see the last comment here: 
http://bugs.php.net/bug.php?id=36607

[2007-05-10 02:27 UTC] brian dot kao at gateway dot com

Thanks to the help from Chirstopher Jones, an Oracle/PHP consultant, Oracle is logging a bug for this issue.  For anyone having the same issue, the bug id is 6039623.  Hopefully, Oracle will have a fix soon.

[2007-05-15 18:02 UTC] sixd@php.net

One potential workaround is to modify php_oci_statement_set_prefetch()
in oci8_statement.c and comment out either the lines that set the
prefetch memory limit, or comment out the lines that set the prefetch
row limit.  In my testing the crash only occurred when both memory and
row limits were set (and you use a DB link and you have the right data
to trigger the crash).  Confirmation or contradiction welcome.

[2008-03-04 21:51 UTC] sixd@php.net

+-------------------------------------------------------
| PHP 5.3 and PHP 6 now use oci8.default_prefetch and
| oci_set_prefetch() to limit only the number of rows.  This is as
| documented.  Previously the row limit was used in conjunction with
| a memory size limit heuristic.  The memory limit caused a crash in
| Oracle for some fetched data sizes. (Oracle bug 6039623)
+-------------------------------------------------------

	php.net \| support \| documentation \| report a bug \| advanced search \| search howto \| statistics \| random bug \| login
go to bug id or search bugs for


Copyright © 2001-2024 The PHP Group All rights reserved.	Last updated: Sat Dec 21 12:01:31 2024 UTC