php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #24003 after several connections to Oracle 9i, program dies
Submitted: 2003-06-03 17:16 UTC Modified: 2003-06-04 08:26 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: dkruger at stevens-tech dot edu Assigned:
Status: Not a bug Package: OCI8 related
PHP Version: 4.3.2 OS: Redhat 8.0
Private report: No CVE-ID: None
 [2003-06-03 17:16 UTC] dkruger at stevens-tech dot edu
The following code used to work on Oracle 8.0 on Solaris.
Now, under Redhat 8.0 and Oracle 9i, when you run it several times in a row, it eventually seg faults and the only way to re-establish the connection is by restarting apache.

Our PHP is built with
./configure  --prefix=usr/local/php --with-gd=/usr/local --with-png-dir=/usr/local --with-oci8=/oracle --with-apx2=/usr/local/apache/bin/apxs --with-jpeg-dir=/usr --with-zlib-dir=/usr --with-xpm-dir=/usr --enable-debug --enable-sigchild

This is not my code, and I do not use PHP, so I want to know first if there is a better way of writing this code. Can it successfully recover given that it dies for some reason on a query? Is there any more recoverable way of writing it?
Even if it's not optimal code, it should be slightly more recoverable than this.

print "Test";
putenv("ORACLE_SID=coastal");
putenv("ORACLE_HOME=/oracle");
putenv("TNS_ADMIN=/oracle/network/admin/tnsnames.ora");
$connection = OCILogon("user","xxx", "mydb") or die("Couldn't logon.");
$sql = "select count(*) from x";
$sql_statement = OCIParse($connection,$sql) or die("Couldn't parse statement.");
OCIExecute($sql_statement, OCI_DEFAULT) or die("Couldn't execute statement.");
$num_columns = OCINumCols($sql_statement);
OCIFreeStatement($sql_statement);
OCILogoff($connection);

PHP still runs after this code, as long as the page does not involve any other Oracle interaction.

thanks!
Dov

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-06-04 08:24 UTC] e_zagrai at yahoo dot com
I've got exectly the same problem and I tryed to use the CVS snapshot you proposed, but the result is the same as it was before: I execute my programm with Oracle interaction for 2-3 times and then I get the error "Document contains no data" every time I try to connect to Oracle in my programm. If I execute any other php without Oracle interaction - it works. 
Apache's error log contains the line:  
[Wed Jun 04 09:16:40 2003] [notice] child pid 3340 exit signal Segmentation fault (11)

Thanks,

Elena
 [2003-06-04 08:26 UTC] derick@php.net
As our documentation describes, you need to set the environment vars BEFORE you start apache. Setting it in a script won't work:
putenv("ORACLE_SID=coastal");
putenv("ORACLE_HOME=/oracle");
putenv("TNS_ADMIN=/oracle/network/admin/tnsnames.ora");

 [2003-06-04 08:43 UTC] e_zagrai at yahoo dot com
I tryed to backtrace the error and that's what I've got:


[root@cmn bin]# gdb /usr/local/apache/bin/httpd
GNU gdb Red Hat Linux (5.2.1-4)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(gdb) run -X
Starting program: /usr/local/apache/bin/httpd -X
[New Thread 8192 (LWP 3518)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 8192 (LWP 3518)]
0x405fddfa in kpuhhaloc () from /oracle/lib/libclntsh.so.9.0
(gdb) bt
#0  0x405fddfa in kpuhhaloc () from /oracle/lib/libclntsh.so.9.0
#1  0x4060e15f in kpughndl0 () from /oracle/lib/libclntsh.so.9.0
#2  0x40614543 in kpughndl () from /oracle/lib/libclntsh.so.9.0
#3  0x40668dd6 in OCIHandleAlloc () from /oracle/lib/libclntsh.so.9.0
#4  0x402ebb93 in _oci_open_session (server=0x81d3d60, username=0x81ed764 "xxx", password="xxx", persistent=0,
    exclusive=0, charset=0x403eb827 "") at /arc/php-4.3.2/ext/oci8/oci8.c:2253
#5  0x402ed1e4 in oci_do_connect (ht=3, return_value=0x81ed84c, this_ptr=0x0, return_value_used=1, persistent=0, exclusive=0)
    at /arc/php-4.3.2/ext/oci8/oci8.c:2685
#6  0x402f19d4 in zif_ocilogon (ht=3, return_value=0x81ed84c, this_ptr=0x0, return_value_used=1) at /arc/php-4.3.2/ext/oci8/oci8.c:4307
#7  0x403dd592 in execute (op_array=0x81d20c4) at /arc/php-4.3.2/Zend/zend_execute.c:1606
#8  0x403cc1bd in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /arc/php-4.3.2/Zend/zend.c:869
#9  0x40396464 in php_execute_script (primary_file=0xbffff600) at /arc/php-4.3.2/main/main.c:1671
#10 0x403e32a5 in php_handler (r=0x81dc998) at /arc/php-4.3.2/sapi/apache2handler/sapi_apache2.c:525
#11 0x080903e6 in ap_run_handler (r=0x81dc998) at config.c:195
#12 0x080908fe in ap_invoke_handler (r=0x81dc998) at config.c:401
#13 0x08080813 in ap_process_request (r=0x81dc998) at http_request.c:288
#14 0x0807ca51 in ap_process_http_connection (c=0x81c8920) at http_core.c:293
#15 0x080993d6 in ap_run_process_connection (c=0x81c8920) at connection.c:85
#16 0x0808ef9c in child_main (child_num_arg=0) at prefork.c:696
#17 0x0808f146 in make_child (s=0x80f0c08, slot=0) at prefork.c:736
#18 0x0808f19f in startup_children (number_to_start=5) at prefork.c:808
#19 0x0808f891 in ap_mpm_run (_pconf=0x808e878, plog=0x8125e70, s=0x80f0c08) at prefork.c:1024
#20 0x080945aa in main (argc=2, argv=0xbffff8d4) at main.c:660
#21 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6

Hopefully it can help somehow...
 [2003-06-04 08:45 UTC] e_zagrai at yahoo dot com
The variables $ORACLE_HOME and others were set before apache started - it didn't help...
 [2003-06-16 02:39 UTC] j dot henge-ernst at interexa dot de
We encountered the same problem, but it seem to be a oracle9 (9ir2) issue. After switching back to oracle 8 everything works as expected.

With PHP 4.2.3 and oracle 9 it works, but with 4.3.2 not. 
Today I tried a latest snap-shot ( php4-STABLE-200306131730 ) and it seems to work again as expected.

No segfault or stange SQL-errors.
 [2003-06-23 14:44 UTC] andre_nasser at yahoo dot com dot br
Friends, I am an Oracle DBA and I supporting a team developing with PHP and we are facing this very issue. Questions:

1) When you say it works with Oracle8 -- is it olny the client or the Oracle server ?

2) We would like to know if this workaround is only for Oracle8 (8.0.x) or does it also work for Oracle8i (8.1.x) ? 

Thanks, Andre
 [2003-07-21 11:29 UTC] mlucero at austin dot rr dot com
I am a developer setting up oracle 9ir2 client under redhat with apache 1.3.27-2 and this is the exact same issue.. identical, however the cvs snapshots did not help me, i continue to have the same issue with it, would it be recommendable to downgrade? or has there been a specific fix released for this?
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Apr 23 14:01:31 2024 UTC