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
 [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

Add a Patch

Pull Requests

Add a Pull Request

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-2024 The PHP Group
All rights reserved.
Last updated: Wed Apr 24 17:01:30 2024 UTC