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

It worked, It worked, It worked!! Your magic fd-patch did the trick. No more spontaneous apache SIGSEGVs. This patch is being included in the next release version, yes? Also, I've had no real trouble out of mod_auth_oracle and PHP... it works quite well in my environment. kevin -- Kevin Hendrix Programmer - PennyPI, LLC. khendrix@pennypi.com http://www.pennypi.com/ - kevin Of yuendrikh - International Man of Mystery thies@digicol.de wrote: > > 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 > > > -- > 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 >