|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2004-10-12 17:22 UTC] subscription at nazarenko dot net
Description: ------------ Very similar to Bug #30410. ocilogon() causes Apache to crash with Segmentation Fault 11. The crashes do not happen EVERY time, however around 90% of page loads are unsuccessful. Machine config: * 2xCPU Intel arch * SuSE 8.2 with 2.40.20-SMP kernel * Apache 2.0.52 - Prefork * Oracle Client 9.2.0 * PHP 5.0.2 with OCI8 support compiled in. Full configure command: ./configure \ --prefix=/usr/lib/apache2-prefork --datadir=/usr/share/php \ --bindir=/usr/bin \ --libdir=/usr/share \ --with-config-file-path=/etc/php \ --with-exec-dir=/etc/php/exec \ --enable-bcmath \ --enable-calendar \ --enable-discard-path \ --enable-exif \ --enable-force-cgi-redirect \ --enable-ftp \ --enable-magic-quotes \ --enable-mbstring \ --enable-memory-limit \ --enable-safe-mode \ --enable-shmop \ --enable-sigchild \ --enable-sysvsem \ --enable-sysvshm \ --enable-versioning \ --enable-wddx \ --with-bz2 \ --with-dom \ --with-ftp \ --with-gettext \ --with-gmp \ --with-jpeg-dir=/usr \ --with-mcal=/usr \ --with-mcrypt \ --with-mysql=/usr/lib/mysql \ --with-mysql-sock=/srv/mysql/mysql.sock \ --with-png-dir=/usr \ --with-tiff-dir=/usr \ --with-xml \ --with-xpm-dir \ --with-zlib \ --with-openssl \ --with-iconv \ --with-oci8=/home/oracle/OraHome1 \ --with-apxs2=/usr/sbin/apxs2-prefork \ --with-gd \ --enable-gd-native-ttf \ --with-ttf \ --with-freetype-dir \ --enable-pcntl Expected result: ---------------- There are a couple of pecularities: * When I tried to run httpd2 with -X parameter from the command line, I noticed that there was only one thread started (I presume this is normal). However, after that I could never cause the Apache to crash again. Only with multiple threads this was true. In order to generate the backtrace I run "httpd2 -X" within the gdb session. * PHP 4.3.x versions work absolutely fine with exactly the same configuration without any crashes. * Both PHP4 and PHP5 exhibit "segfaults (11)" messages when apache-worker MPM is used. See bug #28603 that I reported some time ago. I believe this might be somehow connected, but whereas in the past OCI8 was not correctly working only with the worker MPM, it now crashes even with the prefork MPM, making it impossible to run in a productive environment. Actual result: -------------- gdb backtrace: (gdb) run -X -f /etc/apache2/httpd.conf Starting program: /usr/sbin/httpd2-prefork -X -f /etc/apache2/httpd.conf (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...[New Thread 16384 (LWP 13424)] (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 13424)] 0x40edae91 in snauca_check_adapter () from /home/oracle/OraHome1/lib/libclntsh.so.9.0 (gdb) bt #0 0x40edae91 in snauca_check_adapter () from /home/oracle/OraHome1/lib/libclntsh.so.9.0 #1 0x40ed9614 in nau_viat () from /home/oracle/OraHome1/lib/libclntsh.so.9.0 #2 0x40ed290c in nau_gettab () from /home/oracle/OraHome1/lib/libclntsh.so.9.0 #3 0x40ed0f8b in nau_ini () from /home/oracle/OraHome1/lib/libclntsh.so.9.0 #4 0x40ec68f3 in nainit () from /home/oracle/OraHome1/lib/libclntsh.so.9.0 #5 0x40e7af77 in nsnainit () from /home/oracle/OraHome1/lib/libclntsh.so.9.0 #6 0x40e702ba in nsopen () from /home/oracle/OraHome1/lib/libclntsh.so.9.0 #7 0x40e593d9 in nscall1 () from /home/oracle/OraHome1/lib/libclntsh.so.9.0 #8 0x40e58910 in nscall () from /home/oracle/OraHome1/lib/libclntsh.so.9.0 #9 0x40eef934 in niotns () from /home/oracle/OraHome1/lib/libclntsh.so.9.0 #10 0x40eeb649 in nigcall () from /home/oracle/OraHome1/lib/libclntsh.so.9.0 #11 0x40e88b93 in osncon () from /home/oracle/OraHome1/lib/libclntsh.so.9.0 #12 0x40cc4913 in kpuadef () from /home/oracle/OraHome1/lib/libclntsh.so.9.0 #13 0x40d47ae5 in upiini () from /home/oracle/OraHome1/lib/libclntsh.so.9.0 #14 0x40d36e3b in upiah0 () from /home/oracle/OraHome1/lib/libclntsh.so.9.0 #15 0x40c9eed6 in kpuatch () from /home/oracle/OraHome1/lib/libclntsh.so.9.0 #16 0x40d2afbc in OCIServerAttach () from /home/oracle/OraHome1/lib/libclntsh.so.9.0 #17 0x405d241b in COMP_str_reasons () from /usr/lib/apache2-prefork/libphp5.so #18 0x405d2fcb in COMP_str_reasons () from /usr/lib/apache2-prefork/libphp5.so #19 0x405da68e in COMP_str_reasons () from /usr/lib/apache2-prefork/libphp5.so #20 0x40753368 in COMP_str_reasons () from /usr/lib/apache2-prefork/libphp5.so #21 0x40753ae1 in COMP_str_reasons () from /usr/lib/apache2-prefork/libphp5.so #22 0x4074f95e in COMP_str_reasons () from /usr/lib/apache2-prefork/libphp5.so #23 0x4072b9c5 in COMP_str_reasons () from /usr/lib/apache2-prefork/libphp5.so #24 0x406e5360 in COMP_str_reasons () from /usr/lib/apache2-prefork/libphp5.so #25 0x4075c906 in COMP_str_reasons () from /usr/lib/apache2-prefork/libphp5.so #26 0x08069bb8 in ap_run_handler () #27 0x0806a2c9 in ap_invoke_handler () #28 0x080664d8 in ap_process_request () #29 0x08060f3e in ap_process_http_connection () #30 0x08075248 in ap_run_process_connection () #31 0x0807562e in ap_process_connection () #32 0x08067e74 in child_main () #33 0x08068022 in make_child () #34 0x0806813c in startup_children () #35 0x0806899d in ap_mpm_run () #36 0x0806fd0f in main () #37 0x402148ae in __libc_start_main () from /lib/libc.so.6 (gdb) PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Tue Oct 28 09:00:01 2025 UTC |
Let me confirm it again after some more testing today that I still do get segfaults, but not that often than before. Also, let me point out that it seems to be exclusively Apache/PHP problem. The same script is run from the shell environment with no problems at all. Now to the example that you have asked for. It is really simple. In fact *any* Oracle query will cause occasional browser "hanging". Here is a bit of code I used today for testing: <?php $db_conn = ocilogon( "user", "password", "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=myoracle)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=CRPT)))") or die("Critical Error: No connection to Oracle!"); $cmdstr = " SELECT DISTINCT TRIM(XM.X_MEMBER_ID) MEMBER_ID, S.X_MEMBER_ID DBS_ID FROM TABLE_SITE_PART SP, TABLE_SITE_PART SP2, TABLE_X_MEMBERDATA XM, TABLE_SITE S WHERE SP2.X_CLASS_KEY = 9 AND SP2.LEVEL_TO_BIN IN (0,1,2,3,4,5) AND SP2.SITE_PART2SITE_PART = SP.OBJID AND SP2.X_SITE_PART2MEMBERDATA = XM.OBJID AND SP.ALL_SITE_PART2SITE = S.OBJID AND XM.X_STATUS = 'Active' AND S.STATUS = '0' ORDER BY TRIM(XM.X_MEMBER_ID) "; $parsed = ociparse($db_conn, $cmdstr); ociexecute($parsed); $boxrows = ocifetchstatement($parsed, $listbox); OCIFreeStatement($parsed); print_r($listbox); ?> Most of the times this would work fine returning me an array of data. But sometimes the browser would just wait with nothing happening. And very rarely the page would fail immediately (producing a segfault in apache's error log) Hope this helps.