php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #22929 pb of exit handler in OCI8 module
Submitted: 2003-03-27 09:45 UTC Modified: 2003-11-25 15:31 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:0 (0.0%)
From: soula at lifl dot fr Assigned:
Status: No Feedback Package: OCI8 related
PHP Version: 4.3.3RC4-dev OS: tru64
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: soula at lifl dot fr
New email:
PHP Version: OS:

 

 [2003-03-27 09:45 UTC] soula at lifl dot fr
I use php4-STABLE-200303241630 version, Oracle-8.1.7 and Tru64/5.1 .

Note: For technical reason, we have clear the OCI_SHARED in the OCI8 initialize call (cf. #22927)

The Oracle client (libclntsh.so) set a exit handler via "atexit()" when we connect DB. But PHP unload the module and le library before exiting and so the handler doesn't exist any more and cause a SIGSEGV.

The solution we found is either commenting the "dlclose()" in zend_API.c or compiling OCI8 module in static.


Here the compilation config :

Configure Command =>  './configure'
'--prefix=/usr/local/php-200303241630-ap1' '--enable-memory-limit'
'--enable-shared' '--enable-sockets' '--enable-trans-sid'
'--enable-debug' '--with-config-file-path=/usr/local/lib'
'--with-apxs=/usr/local/apache/bin/apxs' '--enable-debugger=yes'
'--enable-safe-mode' '--with-exec-dir=/usr/bin' '--with-mod_charset'
'--with-openssl' '--with-bz2' '--with-zlib-dir' '--with-gettext'
'--with-kerberos' '--with-regex=system' '--with-zlib' '--with-gd=shared'
'--with-jpeg-dir=/usr/local/jpeg/lib' '--with-png-dir=/usr/local/lib'
'--with-xpm-dir=/usr/local/lib'
'--with-oci8=shared,/usr/oracle/product/8.1.6' '--with-ldap=shared'
'--with-mysql=shared,/usr/local/mysql'
'--with-pgsql=shared,/usr/local/pgsql'


Sincerly,
-- Julien

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-03-27 12:14 UTC] michael dot mauch at gmx dot de
Yes, I see this too on Linux (latest CVS with #undef HAVE_OCI8_SHARED_MODE in oci8.c).

# php -r 'if(!extension_loaded("oci8")) dl("oci8.so"); print_r(ocilogon("user","pw"));'

Resource id #6zsh: segmentation fault (core dumped)  php -r
 [2003-04-10 13:05 UTC] michael dot mauch at gmx dot de
php4-STABLE-200304101530 works fine for me on Linux and on Tru64 5.1. No core dump anymore (and the OCI_SHARED problem is also fixed).
 [2003-07-13 12:48 UTC] soula at lifl dot fr
I've just tested php4-STABLE-200307110730 and it does exactly the same error :


        thread 0xb signal Segmentation fault at
        warning: PC value 0x30003f37d60 not valid, trying RA
        > [exit, 0x3ff800d8850]         ldq     t0, 8(s0)
        (dbx) where
           0 exit(0x1, 0x14004f170, 0x1201557b8,0x14004f170, 0x1201557a4) [0x3ff800d8850]
           1 main() ["/usr/local/tmp/php4-STABLE-200307110730/sapi/cli/php_cli.c":6, 0x1201557b4]



Before the unload of OCI modules(php_module_shutdown), the faulty @ is well defined :


(dbx) 0x30003f37d60/i
  [epc_exit_handler:692, 0x30003f37d60] ldah  gp, 16387(t12)


--
Julien
 [2003-11-17 23:33 UTC] sniper@php.net
Please try with latest CVS snapshot and also using this configure line:

# ./configure --disable-all --with-oci8=/usr/oracle/product/8.1.6 --enable-debug

And if it still crashes, provide a GDB backtrace.

 [2003-11-25 15:31 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.


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Apr 18 20:01:30 2024 UTC