php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #24343 Oracle 9.2.0 client libs do not work
Submitted: 2003-06-26 06:36 UTC Modified: 2006-04-12 14:14 UTC
Votes:13
Avg. Score:4.2 ± 1.0
Reproduced:13 of 13 (100.0%)
Same Version:2 (15.4%)
Same OS:4 (30.8%)
From: thomas at fivemile dot net Assigned:
Status: Closed Package: OCI8 related
PHP Version: 4.3.3-dev OS: Redhat Linux 8.0
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: thomas at fivemile dot net
New email:
PHP Version: OS:

 

 [2003-06-26 06:36 UTC] thomas at fivemile dot net
Description:
------------
OCILogon and OCIPLogon either segfault or return spurious (changing by reloading the page) error messages of the type "Warning: ocilogon(): OCISessionBegin: ORA-00604: error occurred at recursive SQL level 1 ORA-00911: invalid character in /home/httpd/index.php3 on line 5"

Environment vars are set (verfied by phpinfo()), sqlplus from the webserver account works, older (9.0.1) client libs from another machine can access the db without problems.

PHP compiled with ./configure' '--with-db' '--with-apxs2=/usr/bin/apxs' '--with-gd=/usr/local' '--enable-gd-native-ttf' '--with-mysql=/usr' '--with-zlib' '--with-mcrypt' '--enable-track-vars=yes' '--with-jpeg-dir=/usr' '--with-oci8=/opt/oracle/product/9.2.0' '--with-tiff-dir=/usr' '--with-png-dir=/usr' '--with-xml' '--with-calendar' '--enable-sigchild' '--with-xpm-dir=/usr/X11R6' '--with-gettext' '--with-openssl=/usr' '--enable-calendar' '--enable-gd-imgstrttf' '--with-ttf=/usr/local' '--with-imap' '--with-kerberos' '--enable-xslt' '--with-xslt-sablot' '--enable-debug' 

but a 'watered down' version including only the oracle libs yields the same problems, regardless of trying with apache 1 (both static and DSO) or 2


Reproduce code:
---------------
$ohnd = OCILogon("dvd","hidden","tns.domain");

Expected result:
----------------
Connection to Oracle 9.2.0 on the same machine

Actual result:
--------------
Spurious ORA-00604 error messages (see above) or coredump

[root@tesla apache2]# gdb 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"...(no debugging symbols found)...
(gdb) run -X
Starting program: /opt/apache2/bin/httpd -X
(no debugging symbols found)...(no debugging symbols found)...[New Thread 16384 (LWP 1468)]
[Thu Jun 26 13:20:22 2003] [warn] module php4_module is already loaded, skipping

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 1468)]
0x40a94e0a in kpuhhaloc () from /opt/oracle/product/9.2.0/lib/libclntsh.so.9.0
(gdb) bt
#0  0x40a94e0a in kpuhhaloc () from /opt/oracle/product/9.2.0/lib/libclntsh.so.9.0
#1  0x40aa516f in kpughndl0 () from /opt/oracle/product/9.2.0/lib/libclntsh.so.9.0
#2  0x40aab553 in kpughndl () from /opt/oracle/product/9.2.0/lib/libclntsh.so.9.0
#3  0x40affde6 in OCIHandleAlloc () from /opt/oracle/product/9.2.0/lib/libclntsh.so.9.0
#4  0x4035974f in _oci_open_session (server=0x8229608, username=0x82439dc "dvd", password=0x82492fc "yami", persistent=0, exclusive=0, charset=0x404c6cd9 "")
    at /root/build/php-4.3.2/ext/oci8/oci8.c:2253
#5  0x4035ada0 in oci_do_connect (ht=3, return_value=0x8243a4c, this_ptr=0x0, return_value_used=1, persistent=0, exclusive=0)
    at /root/build/php-4.3.2/ext/oci8/oci8.c:2685
#6  0x4035f590 in zif_ocilogon (ht=3, return_value=0x8243a4c, this_ptr=0x0, return_value_used=1) at /root/build/php-4.3.2/ext/oci8/oci8.c:4307
#7  0x404582be in execute (op_array=0x823a31c) at /root/build/php-4.3.2/Zend/zend_execute.c:1606
#8  0x40446ee9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /root/build/php-4.3.2/Zend/zend.c:869
#9  0x40410990 in php_execute_script (primary_file=0xbfffdc20) at /root/build/php-4.3.2/main/main.c:1671
#10 0x4045dfd1 in php_handler (r=0x8207968) at /root/build/php-4.3.2/sapi/apache2handler/sapi_apache2.c:525
#11 0x0809f7fe in ap_run_handler ()
#12 0x0809fd16 in ap_invoke_handler ()
#13 0x080822a3 in ap_process_request ()
#14 0x0807e4e1 in ssl_dh_GetParamFromFile ()
#15 0x080a87ee in ap_run_process_connection ()
#16 0x0809e3b4 in ap_graceful_stop_signalled ()
#17 0x0809e55e in ap_graceful_stop_signalled ()
#18 0x0809e5b7 in ap_graceful_stop_signalled ()
#19 0x0809eca9 in ap_mpm_run ()
#20 0x080a39c2 in main ()
#21 0x420158f7 in __libc_start_main () from /lib/i686/libc.so.6
(gdb) quit

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-06-26 16:03 UTC] thomas at fivemile dot net
The snapshot seems to have cleared the segfaults, nevertheless the weird oracle error messages remain. Is there a way to debug the OCI(P)Logon and compare it with the data the working server is sending?
 [2003-06-26 17:54 UTC] sniper@php.net
Have you set all the necessary environment variables correctly when you start apache?

 [2003-06-26 18:23 UTC] thomas at fivemile dot net
environment of the defunct server (from phpinfo())

NLS_LANG  german_germany.WE8DEC  
LD_LIBRARY_PATH  /opt/oracle/product/9.2.0/lib:/lib:/usr/lib:/opt/apache2/lib::/usr/local/lib  
ORACLE_SID  tsid  
ORACLE_BASE  /opt/oracle  
PATH  /sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/opt/oracle/product/9.2.0/bin  
PWD  /  
LANG  en_US.UTF-8  
ORACLE_TERM  xterm  
SHLVL  1  
ORA_NLS33  /opt/oracle/product/9.2.0/ocommon/nls/admin/data  
ORACLE_HOME  /opt/oracle/product/9.2.0  
_  /sbin/initlog  

and the environment of the working server:

PWD /home 
ORACLE_SID TSID 
LD_LIBRARY_PATH /opt/oracle/product/9.0.1/lib:/lib:/usr/lib:/usr/local/lib 
CLASSPATH /opt/oracle/product/9.0.1/JRE:/opt/oracle/product/9.0.1/jlib:/opt/oracle/product/9.0.1/rdbms/jlib:/opt/oracle/product/9.0.1/network/jlib 
LANG en_US 
ORACLE_BASE /opt/oracle 
ORACLE_HOME /opt/oracle/product/9.0.1 
ORACLE_TERM 386 
SHLVL 3 
ORA_NLS33 /opt/oracle/product/9.0.1/ocommon/nls/admin/data 
PATH /sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin 
NLS_LANG german_germany.WE8DEC 
_ /sbin/initlog 

if i log into the webserver user on the non-functioning host i can access the oracle db with sql*plus just fine.
 [2003-06-26 18:30 UTC] sniper@php.net
With what script and what errors do you get..?

 [2003-06-26 18:36 UTC] thomas at fivemile dot net
Warning: ociplogon(): OCISessionBegin: ORA-00604: error occurred at recursive SQL level 1 ORA-00911: invalid character in /home/httpd/index.php3 on line 3

or

Warning: ocilogon(): OCISessionBegin: ORA-00604: error occurred at recursive SQL level 1 ORA-00922: missing or invalid option in /home/httpd/index.php3 on line 3

'Line 3' is simply the OCILogon or OCIPLogon as follows:

$ohnd = OCILogon("dvd","hidden","tns.domain");
 [2003-07-07 19:29 UTC] sniper@php.net
Try a script which has ONLY that one line.
And you're sure your username/password doesn't contain any illegal chars? And your db name is tns.domain ??

 [2003-07-08 10:52 UTC] thomas at fivemile dot net
the SAME script on the SAME machine works with the 9.0.1 client libs I copied over from the other machine. Only the 9.2.0 client libs (using the SAME script, the SAME php, the SAME apache and the SAME configure line) do not work.
 [2003-07-08 11:40 UTC] sniper@php.net
Then use those. Wild guess: The SAME environment vars don't work with DIFFERENT oracle version..

 [2003-07-13 05:54 UTC] thomas at fivemile dot net
Okay, once again, slowly.
- installed a fresh oracle 9.2.0
- installed a fresh apache with PHP and linked against oracle 
- does NOT work
- copied over the entire /opt/oracle/product/9.0.1 tree from another machine where the libs work
- installed a fresh apache with PHP linked against those other libs
- CHANGED the environment vars so the 9.0.1 libs are used instead of the 9.2.0 libs
- now it works - NO thanks to wild guesses from the bugs team.

i have installed a couple of working oci/php combos so far, the 9.2.0 is the first one where i ran into these kind of problems. And you can't earnestly expect new users to fiddle with libs for 2 weeks till their oci bindings start to work... 

If you like, you can have an account on the box in question and have a look around yourself. However i am NOT satisfied with the answer 'okay, you made a crude hack, and by chance it worked, now use it and stop bugging us'
 [2003-07-13 10:45 UTC] sniper@php.net
Try adding "ociinternaldebug(1);" in the beginning of your script. That'll make the functions to print out some extra debugging information.

 [2003-07-20 10:41 UTC] sniper@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


 [2004-02-14 08:38 UTC] timothy_haak at yahoo dot com
Hi

I am having a similar issue to the person below here is what the screen prints out when I ad the ociinternaldebug(1); to the top of the file.

Warning: ocilogon() [function.ocilogon]: OCISessionBegin: ORA-00604: error occurred at recursive SQL level 1 ORA-00911: invalid character in /Scripts/WEB/test.php on line 3
OCIDebug: _oci_open_session: FAILURE -> CLEANUP called
OCIDebug: START _oci_close_session: logging-off sess=0
OCIDebug: _oci_close_session: logging-off DEAD session
OCIDebug: oci_do_connect: FAILURE -> CLEANUP called
OCIDebug: START _oci_conn_list_dtor: id=0
OCIDebug: END _oci_conn_list_dtor: id=0
Oracle Connect Error OCIDebug: START php_rshutdown_oci
OCIDebug: END php_rshutdown_oci


I have tried compiling with both php versions PHP 5.0 Beta 4  and PHP 4.3.4

Here is what is loaded into my profile.

ORACLE_BASE=/u01/oracle
export ORACLE_BASE
ORACLE_HOME=/u01/oracle/product/9.2
export ORACLE_HOME
ORACLE_SID=PIERCEG
export ORACLE_SID
PATH=$PATH:$HOME/bin:/u01/oracle/product/9.2/bin
export PATH
USERNAME=""
export USERNAME
CLASSPATH=:.:/u01/oracle/product/9.2/jdbc/lib/classes111.zip
export CLASSPATH
LD_LIBRARY_PATH=/u01/oracle/product/9.2/lib
export LD_LIBRARY_PATH
ORA_NLS33=/u01/oracle/product/9.2/ocommon/nls/admin/data
export ORA_NLS3
NLS_LANG="ENGLISH_UNITED KINGDOM.WE8MSWIN1252"
export NLS_LANG
NLS_DATE_FORMAT="RRRR-MM-DD HH24:MI:SS"
export NLS_DATE_FORMAT
PATH=$PATH:/usr/local/jre/bin
export PATH
LD_ASSUME_KERNEL=2.4.1
export LD_ASSUME_KERNEL


Here is the configuration info

'./configure' '--with-apxs2=/usr/local/apache2/bin/apxs' '--with-oci8' '--enable-track-vars' '--enable-ftp' '--enable-sigchild' '--with-gd' '--enable-gd-native-ttf' '--with-ttf' '--with-freetype-dir=/usr/local/freetype' '--with-jpeg-dir=/usr/lib/' '--with-zlib' '--with-png-dir=/usr/lib/' '--with-xpm-dir=/usr/X11R6' '--with-ldap' '--enable-exif' '--with-png' '--without-tsrm-pthreads' '--enable-inline-optimization' '--with-tiff=/usr/lib/'

From phpinfo

oci8
OCI8 Support 	enabled
Revision 	$Revision: 1.248 $
Active Persistent Links 	0
Active Links 	-3
Oracle Version 	9.2
Compile-time ORACLE_HOME 	/u01/oracle/product/9.2
Libraries Used 	no value
Temporary Lob support 	enabled
Collections support 	enabled
 [2004-02-14 08:46 UTC] timothy_haak at yahoo dot com
Hi sorry ment to add the script as well 

I have also tested connecting from sqlplus which i can do.
<?php
        ociinternaldebug(1);
        if (OCILogon("<username>", "<password>", "pierceg"))
        {
           echo "Successfully connected to Oracle.\n";
        }

        else
        {
           echo "Oracle Connect Error ";
        }

?>
 [2004-04-23 12:54 UTC] timothy_haak at yahoo dot com
Hi

Don't know why but by removing the following variable from my profile I managed to get it to work.

NLS_LANG="ENGLISH_UNITED KINGDOM.WE8MSWIN1252"
export NLS_LANG

Hope this helps
 [2004-04-23 13:01 UTC] tony2001@php.net
I would be very thankful, if you try it without this fix, but with latest PHP5 snapshot.
BTW, Apache2 is NOT recommended for use in production, so if you want it to be stable, you need to use Apache 1.3.x.
 [2004-09-07 19:28 UTC] roman_petrov at gorodok dot net
I have this problem to:
I install Oracle 9.2.0, PHP 5.0.1 o(also I try PHP 4.3.8), apache 2.0.50 and get an error when connect to my database with NLS_LANG another, than AMERICAN.
My configure command is:
Configure Command './configure' '--with-apxs2=/usr/local/apache2/bin/apxs' '--without-mysql'   '--with-pgsql' '--with-oci8=/opt/oracle/product/9.2.0'
'--with-oracle=/opt/oracle/product/9.2.0' '--with-zlib'
 '--enable-sigchild'
My PHPinfo said:
oci8

   OCI8 Support             enabled
   Revision                 $Revision: 1.257 $
   Active Persistent Links  0
   Active Links             0
   Oracle Version           9.2
   Compile-time ORACLE_HOME /opt/oracle/product/9.2.0
   Libraries Used           no value
   Temporary Lob support    enabled
   Collections support      enabled

oracle

   Oracle Support           enabled
   Oracle Version           9.0
   Compile-time ORACLE_HOME /opt/oracle/product/9.2.0
   Libraries Used           no value

I set NLS_LANG=RUSSIAN.CL8KOI8R
Error is
   OCIDebug: _oci_open_server new conn=0 dname=xxx
   Warning:         oci_new_connect()         [function.oci-new-connect]:
   OCISessionBegin:  ORA-00604:  error  occurred at recursive SQL level 1
   ORA-00911: invalid character in /home/www/test.php on line 21
   OCIDebug: _oci_open_session: FAILURE -> CLEANUP called

When I set NLS_LANG=AMERICAN , connect work and my query return data. But I need  NLS_LANG=RUSSIAN.CL8KOI8R
 for my Russian symbols. 
Also, oracle (not oci8) functions in PHP work and get me a data with my language.
Please, help to me.
 [2006-04-12 14:07 UTC] michael at six dot de
Right now I had the same error on an older php installation: apache 1.3.31, php 4.3.8, oracle 9.2 (suse linux 9.3). The problem seems to come up when glibc and oracle nls environment variables are not consistent. The original bug report mentions

LANG=en_US.UTF-8
NLS_LANG=german_germany.WE8DEC

in the non working installation whereas it is

LANG=en_US
NLS_LANG=german_germany.WE8DEC

in the working installation. For me it was

unset LANG
LC_CTYPE=de_DE.UTF-8
NLS_LANG=GERMAN_GERMANY.WE8ISO8859P1

in the non working case. When unsetting LC_CTYPE everything is ok. Newer suse linux distributions (others too) in general have utf-8 environment variables set. In my case it looks like LC_CTYPE was added in suse 9.3. It seems that system and oracle nls environments simply have to be consistent, for example:

LANG=de_DE.UTF-8
NLS_LANG=GERMAN_GERMANY.UTF8

works without a problem.
 [2006-04-12 14:14 UTC] tony2001@php.net
Thank you for your bug report. This issue has already been fixed
in the latest released version of PHP, which you can download at 
http://www.php.net/downloads.php


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Nov 24 07:02:12 2024 UTC