Problem: Apache + mod_ssl + PHP4 + Oracle 8i + mod_auth_oracle

From: Date: Fri, 28 Jul 2000 15:52:05 +0000
Subject: Problem: Apache + mod_ssl + PHP4 + Oracle 8i + mod_auth_oracle
Groups: php.general 
Request: Send a blank email to php-general+get-8800@lists.php.net to get a copy of this message
Hi. I've cross posted this message modssl-users, php-dev, and some other oracle related mailing lists because don't know where the problem is at this time. Any help or suggestions would be appreciated. My environment is Redhat Linux 6.2 Apache 1.3.12 OpenSSL 0.9.5a mod_ssl 2.6.5-1.3.12 mod_auth_oracle PHP 4.0.1 pl2 Oracle 8i (8.1.6) My problem is that Apache processes die from segmentation fault in certain circumstances only. I have apache configured with a virtual server running on port 80 and on port 443 (if SSL is enabled). The server documentroot is authenticated using mod_auth_oracle. I have an alias to a non-authenticated directory, also. In each of the directories (auth and nonauth), I have a simple PHP script that connects to Oracle and calls the OCIServerVersion() PHP function. An apache process dies in segmentation fault when the 2nd PHP document that calls Oracle is requested ONLY when - Apache is running in SSL mode, e.g.: ./httpd -DSSL -X - The PHP document that connects to oracle uses a persistent oracle connection by using the OCIPLogon() PHP function. - The first PHP document that uses Oracle is in the 'authenticated' portion of the web site. I've tried a number of things already in my attempts to identify where the problem is. - I've compiled each module (auth_oracle, PHP, and mod_ssl) static and as DSO in many combinations ... the problem exists the same in all cases. - The problem exists connecting to the web server on port 80 or SSL on port 443. - Run apache without SSL enabled (using the same binary), the problem goes away. - Make the 1st PHP document that calls Oracle in the non-authenticated branch of the documentroot, the problem goes away. EVERY subsequent call to the PHP/Oracle test document in either authenticated or non-auth server branch works fine in this case. - Change the PHP document to use a normal oracle connection, OCILogon() rather than OCIPlogon(), the problem goes away. A gdb stack trace follows: Starting program: /usr/apache/1.3.12/bin/./httpd -X -DSSL Program received signal SIGSEGV, Segmentation fault. 0x4016201c in kpuvers () from /usr/oracle/product/8.1.6/lib/libclntsh.so.8.0 (gdb) where #0 0x4016201c in kpuvers () from /usr/oracle/product/8.1.6/lib/libclntsh.so.8.0 #1 0x40198b71 in OCIServerVersion () from /usr/oracle/product/8.1.6/lib/libclntsh.so.8.0 #2 0x80ca091 in php_if_ociserverversion (ht=1, return_value=0x8368dbc, this_ptr=0x0, return_value_used=1) at oci8.c:3781 #3 0x813f5fc in execute (op_array=0x82e93f4) at ./zend_execute.c:1558 #4 0x813f7e1 in execute (op_array=0x82e9394) at ./zend_execute.c:1598 #5 0x813f7e1 in execute (op_array=0x8368264) at ./zend_execute.c:1598 #6 0x80ac8fb in php_execute_script (primary_file=0xbffff8ec) at main.c:1157 #7 0x8125120 in apache_php_module_main (r=0x8315bc0, fd=26, display_source_mode=0) at sapi_apache.c:93 #8 0x80aa6ab in send_php () #9 0x80aa6ec in send_parsed_php () #10 0x8149123 in ap_invoke_handler () #11 0x815cad9 in process_request_internal () #12 0x815cb3c in ap_process_request () #13 0x815434e in child_main () #14 0x81544fc in make_child () #15 0x8154659 in startup_children () #16 0x8154c86 in standalone_main () #17 0x8155423 in main () #18 0x407359cb in __libc_start_main (main=0x81550cc <main>, argc=3, argv=0xbffffaa4, init=0x80827c4 <_init>, fini=0x81f70fc <_fini>, rtld_fini=0x4000ae60 <_dl_fini>, stack_end=0xbffffa9c) at ../sysdeps/generic/libc-start.c:92 (gdb) quit This is clearly a crash in the PHP module. Watching connections to the database from the "Oracle" side of things shows that the connection from PHP (supposedly persistant) is disappearing in my test case. The next attempt to use the (now defunct) oracle connection by PHP causes the SIGSEGV. I'm tapped out. Any ideas? I'm reading the PHP oci8.c source code now in an attempt to eyeball a cause ... probably futile, but I've got no other recourse right now. thanks! kevin -- Kevin Hendrix Programmer - PennyPI, LLC. khendrix@pennypi.com http://www.pennypi.com/ - kevin Of yuendrikh - International Man of Mystery

« previous php.general (#8800) next »