php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #13297 segfault in ociparse()
Submitted: 2001-09-13 22:30 UTC Modified: 2001-09-27 06:58 UTC
From: graeme at i7 dot com dot au Assigned:
Status: Closed Package: OCI8 related
PHP Version: 4.0.6 OS: Solaris-2.6
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: graeme at i7 dot com dot au
New email:
PHP Version: OS:

 

 [2001-09-13 22:30 UTC] graeme at i7 dot com dot au
Using gcc-2.95.3
Configure line:
"./configure" \
"--enable-debug" \
"--enable-libgcc" \
"--with-apxs=/usr/local/apache/bin/apxs" \
"--without-mysql" \
"--enable-magic-quotes" \
"--enable-track-vars" \
"--enable-memory-limit" \
"--with-expat-dir=/usr/local" \
"--with-sablot=shared,/usr/local" \
"--with-oci8=shared,/oracle/product/817" \
"--with-curl=shared" \
"--with-zlib-dir=/local" \
"--with-dom=shared" \
"--enable-shmop"

oci8 and domxml modules currently loaded. Tried altering load order but no difference.

Test script:

<?php
$db = ocilogon("massive","massive", "PLAT");
var_dump($db);

$sql = "SELECT SYSDATE FROM DUAL";
$stmt = ociparse($db, $sql);
var_dump($stmt);
?>


Ouput:
bash-2.05$ php -qe test.php
resource(3) of type (oci8 connection)
resource(4) of type (oci8 statement)
Segmentation Fault (core dumped)


GDB output when stepping thru:
0x24f64 in _start ()
(gdb)

Program received signal SIGSEGV, Segmentation fault.
Cannot access memory at address 0xef22b2c4.


and a backtrace from a core:
Program terminated with signal 11, Segmentation Fault.
Reading symbols from /usr/lib/libpam.so.1...done.
Reading symbols from /usr/lib/libdl.so.1...done.
Reading symbols from /usr/local/lib/libexpat.so.0...done.
Reading symbols from /usr/local/lib/libsablot.so.0...done.
Reading symbols from /usr/local/lib/libz.so...done.
Reading symbols from /usr/lib/libresolv.so.2...done.
Reading symbols from /usr/lib/libm.so.1...done.
Reading symbols from /usr/lib/libnsl.so.1...done.
Reading symbols from /usr/lib/libsocket.so.1...done.
Reading symbols from /usr/lib/libc.so.1...done.
Reading symbols from /usr/lib/libmp.so.2...done.
Reading symbols from /usr/platform/sun4u/lib/libc_psr.so.1...done.
Reading symbols from /usr/lib/nss_files.so.1...done.
#0  0xef22b2c4 in ?? ()
(gdb) bt
#0  0xef22b2c4 in ?? ()
#1  0xef4888ac in exit ()


However the script runs as you'll see from the output. the $stmt resource gets printed. I suspect there's a problem in one of the oracle shutdown functions but I don't know my way around c/gdb well enough

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2001-09-13 22:54 UTC] sniper@php.net
Does this happen with the latest CVS snapshot:

http://snaps.php.net/

 [2001-09-21 07:31 UTC] graeme@php.net
From compliing Oracle not as a .so but as static module in PHP, this error shows up when running configure.

checking for executable suffix... configure: error: installation or configuration problem: compiler cannot create executables.
bash-2.05# tail config.log
configure:59199: checking for object suffix
configure:59205: gcc -c -g -O2  -D_POSIX_PTHREAD_SEMANTICS conftest.c 1>&5
configure:59225: checking for executable suffix
configure:59235: gcc -o conftest -g -O2  -D_POSIX_PTHREAD_SEMANTICS  -R/usr/ucblib -L/usr/ucblib -R/usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.3 -L/usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.3 -R/oracle/product/817/lib -L/oracle/product/817/lib conftest.c -lsched -ldl -lgen -lsocket -lnsl -lcrypt -lresolv -lresolv -lm -ldl -lnsl -lsocket  -lsocket -lgcc -lcrypt -lclntsh 1>&5
Undefined                       first referenced
 symbol                             in file
_delete                             /oracle/product/817/lib/libgen.so.1
_insert                             /oracle/product/817/lib/libgen.so.1
ld: fatal: Symbol referencing errors. No output written to conftest
collect2: ld returned 1 exit status


Which perhaps suggests it's a problem with the Oracle 8.1.7 libs on Solaris?
$LD_LIBRARY_PATH is /vignette/oracle/product/817/lib:/usr/java1.1/lib:/usr/local/lib
in case it's relevant.

 [2001-09-27 06:58 UTC] graeme@php.net
Turns out that our DBA in his infinite wisdom brought over an Oracle install from a Solaris-2.8 box.
Quote: Some of the lib files weren't there so I copied them over from a Solaris-2.8 box as well.

Used Solaris-2.6 libs and whaddaya know? :)
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved.
Last updated: Wed May 07 23:01:27 2025 UTC