php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #28780 Web Server crashes connecting upon OCILogon
Submitted: 2004-06-14 19:31 UTC Modified: 2004-06-29 01:00 UTC
From: reinhard dot e dot voglmaier at gsk dot com Assigned: tony2001 (profile)
Status: No Feedback Package: OCI8 related
PHP Version: 4.3.7 OS: Sun Solaris 9
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: reinhard dot e dot voglmaier at gsk dot com
New email:
PHP Version: OS:

 

 [2004-06-14 19:31 UTC] reinhard dot e dot voglmaier at gsk dot com
Description:
------------
export CFLAGS=-m64
export ORACLE_HOME=/opt/oracl/9.2.0 \
./configure  --with-oracle \
             --with-oci8   

this is the configuration of the build process. When I try to connect to Oracle with the  OCILogon function the web server crashes. It does not write a core dump


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-06-14 19:41 UTC] tony2001@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-06-15 10:53 UTC] reinhard dot e dot voglmaier at gsk dot com
I did'nt get any backtrace, running gdb resulted in:
gdb httpd
(gdb) run -X
procfs: 4265 -- process not stopped
procfs: ...giving up...

httpd is running, I see it via "ps -ef"
calling OCILogin results in Segmentation fault, but the process doesn't stop, I don't get the core file
 [2004-06-15 11:17 UTC] tony2001@php.net
Well.. I can't get a backtrace for you too. 
Btw, you didn't tell your version of Apache (or whatever you use). If you use Apache2, you'd better read this: http://www.php.net/manual/en/install.apache2.php
 [2004-06-15 11:59 UTC] reinhard dot e dot voglmaier at gsk dot com
You're right, 
I use apache 1.3.29

what does this mean ?
procfs: 4265 -- process not stopped
procfs: ...giving up...
 [2004-06-15 12:31 UTC] tony2001@php.net
Seems to be a Solaris-specific GDB bug.
Have a look at these messages: 
http://www.mail-archive.com/bug-gdb@gnu.org/msg00818.html
http://www.mail-archive.com/bug-gdb@gnu.org/msg00452.html

Btw, what Oracle client version do you use and does it correspond to Oracle server version?
 [2004-06-15 12:42 UTC] reinhard dot e dot voglmaier at gsk dot com
I'm using Oracle 9.2.0 same product as I am connecting to. 
Oracle is 64 bit ( -m64 switch for gcc ). I started it 
under truss, here the last few lines: 
 
 
lstat("/opt/apache/itweb/htdocs", 0xFFFFFFFF7FFF80F0) = 0 
getuid()                                        = 60001 
[60001] 
door_info(4, 0xFFFFFFFF7FFF5D68)                = 0 
door_call(4, 0xFFFFFFFF7FFF5D38)                = 0 
sigprocmask(SIG_SETMASK, 0xFFFFFFFF7C91D500, 
0xFFFFFFFF7FFF7C90) = 0 
sigprocmask(SIG_SETMASK, 0xFFFFFFFF7FFF7C7C, 0x00000000) = 
0 
sigaction(SIGINT, 0xFFFFFFFF7FFF7AF0, 0xFFFFFFFF7FFF7CE8) 
= 0 
sigprocmask(SIG_SETMASK, 0xFFFFFFFF7C91D500, 
0xFFFFFFFF7FFF7C90) = 0 
sigprocmask(SIG_SETMASK, 0xFFFFFFFF7FFF7C7C, 0x00000000) = 
0 
brk(0x1004C6210)                                = 0 
brk(0x1004CA210)                                = 0 
brk(0x1004CA210)                                = 0 
brk(0x1004CE210)                                = 0 
brk(0x1004CE210)                                = 0 
brk(0x1004D2210)                                = 0 
door_info(4, 0xFFFFFFFF7FFF4538)                = 0 
door_call(4, 0xFFFFFFFF7FFF4508)                = 0 
brk(0x1004D2210)                                = 0 
brk(0x1004D6210)                                = 0 
so_socket(PF_INET, SOCK_STREAM, IPPROTO_IP, "", 1) = 7 
connect(7, 0xFFFFFFFF7FFF67F4, 16, 1)           = 0 
getsockname(7, 0xFFFFFFFF7FFF67F4, 0xFFFFFFFF7FFF6804, 1) 
= 0 
setsockopt(7, tcp, TCP_NODELAY, 0xFFFFFFFF7FFF6964, 4, 1) 
= 0 
fcntl(7, F_SETFD, 0x00000001)                   = 0 
brk(0x1004D6210)                                = 0 
brk(0x1004DA210)                                = 0 
brk(0x1004DA210)                                = 0 
brk(0x1004DE210)                                = 0 
brk(0x1004DE210)                                = 0 
brk(0x1004FE210)                                = 0 
    Incurred fault #6, FLTBOUNDS  %pc = 0xFFFFFFFF7D63C1AC 
      siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000 
    Received signal #11, SIGSEGV [default] 
      siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000
 [2004-06-16 11:30 UTC] reinhard dot e dot voglmaier at gsk dot com
Maybe there are problems with the 64 bit Environment ? Is PHP + Oracle 64bit safe ? ( Pointer casted into int or unsigned int ? conversions between int ? adress arithmetic used ? )  I am using 64bit Oracle.
 [2004-06-21 14:30 UTC] reinhard dot e dot voglmaier at gsk dot com
Finally I have the trace: 
Starting program: /opt/apache/itweb/sbin/httpd_php/httpd 
-X 
 
Program received signal SIGSEGV, Segmentation fault. 
0xff0b347c in strlen () from /usr/lib/libc.so.1 
(gdb) bt 
#0  0xff0b347c in strlen () from /usr/lib/libc.so.1 
#1  0xfe79f8f8 in snauca_check_adapter () from /opt/oracl/
product/9.2.0/lib32/libclntsh.so.9.0 
#2  0xfe79d8f0 in nau_viat () from /opt/oracl/
product/9.2.0/lib32/libclntsh.so.9.0 
#3  0xfe7944f4 in nau_gettab () from /opt/oracl/
product/9.2.0/lib32/libclntsh.so.9.0 
#4  0xfe7922b8 in nau_ini () from /opt/oracl/
product/9.2.0/lib32/libclntsh.so.9.0 
#5  0xfe783f8c in nainit () from /opt/oracl/product/9.2.0/
lib32/libclntsh.so.9.0 
#6  0xfe734c3c in nsnainit () from /opt/oracl/
product/9.2.0/lib32/libclntsh.so.9.0 
#7  0xfe7271dc in nsopen () from /opt/oracl/product/9.2.0/
lib32/libclntsh.so.9.0 
#8  0xfe70d188 in nscall1 () from /opt/oracl/
product/9.2.0/lib32/libclntsh.so.9.0 
#9  0xfe70c7a8 in nscall () from /opt/oracl/product/9.2.0/
lib32/libclntsh.so.9.0 
#10 0xfe7b8df0 in niotns () from /opt/oracl/product/9.2.0/
lib32/libclntsh.so.9.0 
#11 0xfe7b2954 in nigcall () from /opt/oracl/
product/9.2.0/lib32/libclntsh.so.9.0 
#12 0xfe744de0 in osncon () from /opt/oracl/product/9.2.0/
lib32/libclntsh.so.9.0 
#13 0xfe55f190 in kpuadef () from /opt/oracl/
product/9.2.0/lib32/libclntsh.so.9.0 
#14 0xfe55108c in upiini () from /opt/oracl/product/9.2.0/
lib32/libclntsh.so.9.0 
#15 0xfe55108c in upiini () from /opt/oracl/product/9.2.0/
lib32/libclntsh.so.9.0 
Previous frame identical to this frame (corrupt stack?) 
(gdb)
 [2004-06-21 18:22 UTC] tony2001@php.net
The backtrace shows, that the bug has nothing to do with PHP, but most likely is a Oracle Client problem.
Could you please search Oracle bug database ?
 [2004-06-29 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-2022 The PHP Group
All rights reserved.
Last updated: Thu Aug 11 08:05:57 2022 UTC