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

From: Date: Sat, 29 Jul 2000 10:06:04 +0000
Subject: Re: Problem: Apache + mod_ssl + PHP4 + Oracle 8i + mod_auth_oracle
References: 1  Groups: php.general 
Request: Send a blank email to php-general+get-8937@lists.php.net to get a copy of this message
On Fri, Jul 28, 2000 at 10:52:05AM -0500, Kevin Hendrix wrote: > Hi. please apply the attached patch to you php: cd php-4.0.1_pl2/sapi/apache; patch < fd-patch there is a bug in php 4 (fixed only in current CVS or by applying this patch) that would close some "random" file-descriptor after the script is run. depending on which FD gets closed you can get any weird problem in this world. also somebody has reported that mod_auth_oracle and php don't go well together - he has reported that there's another oracle auth module for apache that uses the oci8 API and works "better" with php. (lost the link, search the archive...) tc > > 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 > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, e-mail: php-general-unsubscribe@lists.php.net > For additional commands, e-mail: php-general-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net -- Thies C. Arntzen "One Big-Mac, Small Fries and a Coke!" Digital Collections Phone +49 40 235350 Fax +49 40 23535180 Hammerbrookstr. 93 20097 Hamburg / Germany

? xx Index: mod_php4.c =================================================================== RCS file: /repository/php4/sapi/apache/mod_php4.c,v retrieving revision 1.56 diff -u -r1.56 mod_php4.c --- mod_php4.c 2000/07/06 17:40:18 1.56 +++ mod_php4.c 2000/07/08 12:57:46 @@ -64,7 +64,7 @@ # include "mod_dav.h" #endif -int apache_php_module_main(request_rec *r, int fd, int display_source_mode CLS_DC ELS_DC PLS_DC SLS_DC); +int apache_php_module_main(request_rec *r, int display_source_mode CLS_DC ELS_DC PLS_DC SLS_DC); void php_save_umask(void); void php_restore_umask(void); int sapi_apache_read_post(char *buffer, uint count_bytes SLS_DC); @@ -439,7 +439,7 @@ int send_php(request_rec *r, int display_source_mode, char *filename) { - int fd, retval; + int retval; HashTable *per_dir_conf; SLS_FETCH(); ELS_FETCH(); @@ -476,11 +476,6 @@ if (filename == NULL) { filename = r->filename; } - /* Open the file */ - if ((fd = popenf(r->pool, filename, O_RDONLY, 0)) == -1) { - log_reason("file permissions deny server access", filename, r); - return FORBIDDEN; - } /* Apache 1.2 has a more complex mechanism for reading POST data */ #if MODULE_MAGIC_NUMBER > 19961007 @@ -514,12 +509,11 @@ add_cgi_vars(r); init_request_info(SLS_C); - apache_php_module_main(r, fd, display_source_mode CLS_CC ELS_CC PLS_CC SLS_CC); + apache_php_module_main(r, display_source_mode CLS_CC ELS_CC PLS_CC SLS_CC); /* Done, restore umask, turn off timeout, close file and return */ php_restore_umask(); kill_timeout(r); - pclosef(r->pool, fd); return OK; } Index: sapi_apache.c =================================================================== RCS file: /repository/php4/sapi/apache/sapi_apache.c,v retrieving revision 1.17 diff -u -r1.17 sapi_apache.c --- sapi_apache.c 2000/06/05 23:21:57 1.17 +++ sapi_apache.c 2000/07/08 12:57:46 @@ -59,23 +59,18 @@ /*#include "mod_php4.h"*/ -int apache_php_module_main(request_rec *r, int fd, int display_source_mode CLS_DC ELS_DC PLS_DC SLS_DC) +int apache_php_module_main(request_rec *r, int display_source_mode CLS_DC ELS_DC PLS_DC SLS_DC) { zend_file_handle file_handle; if (php_request_startup(CLS_C ELS_CC PLS_CC SLS_CC) == FAILURE) { return FAILURE; } -#ifdef PHP_WIN32 /* sending a file handle to another dll is not working // so let zend open it. */ file_handle.type = ZEND_HANDLE_FILENAME; file_handle.handle.fd = 0; -#else - file_handle.type = ZEND_HANDLE_FD; - file_handle.handle.fd = fd; -#endif file_handle.filename = SG(request_info).path_translated; file_handle.free_filename = 0;
« previous php.general (#8937) next »