ID: 14333 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Open Bug Type: Apache related Operating System: RH 6.2 SMP PHP Version: 4.0.6 New Comment:
I just installed the MySQL-devel-3.23.40-1.i386.rpm RPM. It installed the following files: [root@s1 lib]# rpm -q -l MySQL-devel /usr/bin/comp_err /usr/bin/mysql_config /usr/include/mysql /usr/include/mysql/chardefs.h /usr/include/mysql/dbug.h /usr/include/mysql/errmsg.h /usr/include/mysql/history.h /usr/include/mysql/keymaps.h /usr/include/mysql/m_ctype.h /usr/include/mysql/m_string.h /usr/include/mysql/my_config.h /usr/include/mysql/my_global.h /usr/include/mysql/my_list.h /usr/include/mysql/my_net.h /usr/include/mysql/my_no_pthread.h /usr/include/mysql/my_pthread.h /usr/include/mysql/my_sys.h /usr/include/mysql/mysql.h /usr/include/mysql/mysql_com.h /usr/include/mysql/mysql_version.h /usr/include/mysql/mysqld_error.h /usr/include/mysql/raid.h /usr/include/mysql/readline.h /usr/include/mysql/sslopt-case.h /usr/include/mysql/sslopt-longopts.h /usr/include/mysql/sslopt-usage.h /usr/include/mysql/sslopt-vars.h /usr/include/mysql/tilde.h /usr/lib/mysql /usr/lib/mysql/libdbug.a /usr/lib/mysql/libheap.a /usr/lib/mysql/libmerge.a /usr/lib/mysql/libmyisam.a /usr/lib/mysql/libmyisammrg.a /usr/lib/mysql/libmysqlclient.a /usr/lib/mysql/libmysqlclient.la /usr/lib/mysql/libmystrings.a /usr/lib/mysql/libmysys.a /usr/lib/mysql/libnisam.a There isn't a libmysqlclient.so in this list, but there is a libmysqlclient.a. However, it is in /usr/lib/mysql. What line should I use to configure PHP? Is it still: --with-mysql=/usr Or would it be: --with-mysql=/usr/lib/mysql Or something else? Thanks! Previous Comments: ------------------------------------------------------------------------ [2001-12-05 01:26:37] [EMAIL PROTECTED] If you use other module for apache, then PHP only, you _must_ use the MySQL libraries that are installed on your system, but not the bundled once. You should indeed try if --without-mysql would work for you. (Simply leaving out --with-mysql does not work, it's on by default). Derick ------------------------------------------------------------------------ [2001-12-04 17:57:03] [EMAIL PROTECTED] I can't find the libmysqlclient.so file on my system (and definitely not in /usr/lib). MySQL-3.23.40-1 was installed from RPM, not from ApacheToolbox. I don't think I've installed the MySQL-devel package. Do you think this has something to do with the PHP problem? I could try compiling it without the --with-mysql to see if that helps at all. Were the backtraces helpful at all? Thanks again for the help! ------------------------------------------------------------------------ [2001-12-04 08:22:51] [EMAIL PROTECTED] You can try this: Edit the ./configure line for PHP that APT generated: remove: --with-mysql add: --with-mysql=/usr (if libmysqlclient.so is in /usr/lib/) and the rebuild both PHP and apache. Derick ------------------------------------------------------------------------ [2001-12-04 08:11:32] [EMAIL PROTECTED] I just reconfigured and installed Apache 1.3.22 with PHP 4.1.0RC5 support. When I did this, I also added --enable-debug to the PHP configure command-line. I added a CFLAGS="-g" and --without-execstrip to the apache configure command-line. Once I installed and restarted Apache, I waited about 3 or 4 minutes before one of the Apache processes started using up 88% of the CPU. This process grew to consume 99% within the next minute or so. I then ran gdb and attached it to the PID. The following is the output, including a backtrace: [root@s1 apache_1.3.22]# gdb /usr/local/apache/bin/httpd 28070 GNU gdb 19991004 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... /root/atb/Apachetoolbox-1.5.45/apache_1.3.22/28070: No such file or directory. Attaching to program: /usr/local/apache/bin/httpd, Pid 28070 Reading symbols from /lib/libpam.so.0...done. Reading symbols from /lib/libdl.so.2...done. Reading symbols from /usr/local/lib/libgd.so...done. Reading symbols from /usr/local/lib/php/t1libs/lib/libt1.so.1...done. Reading symbols from /usr/local/lib/libfreetype.so.6...done. Reading symbols from /usr/local/lib/libz.so.1...done. Reading symbols from /usr/local/lib/libjpeg.so.62...done. Reading symbols from /lib/libcrypt.so.1...done. Reading symbols from /lib/libresolv.so.2...done. Reading symbols from /lib/libm.so.6...done. Reading symbols from /lib/libnsl.so.1...done. Reading symbols from /lib/libdb.so.3...done. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/ld-linux.so.2...done. Reading symbols from /lib/libnss_files.so.2...done. Reading symbols from /lib/libnss_dns.so.2...done. Reading symbols from /usr/lib/gconv/ISO8859-1.so...done. Reading symbols from /usr/local/apache/libexec/libjrun.so...done. Reading symbols from /usr/local/apache/libexec/mod_caucho.so...done. 0x4020922e in chunk_free (ar_ptr=0x4029dd40, p=0x8cc3b98) at malloc.c:3121 3121 malloc.c: No such file or directory. (gdb) bt #0 0x4020922e in chunk_free (ar_ptr=0x4029dd40, p=0x8cc3b98) at malloc.c:3121 #1 0x40208f9a in __libc_free (mem=0x8ccf458) at malloc.c:3023 #2 0x815765a in shutdown_memory_manager (silent=0, clean_cache=1) at zend_alloc.c:485 #3 0x80c85a5 in php_module_shutdown () at main.c:1007 #4 0x80c855c in php_module_shutdown_wrapper (sapi_globals=0x8367ba0) at main.c:972 #5 0x80c6a15 in php_child_exit_handler (s=0x83aa8a8, p=0x8cf6578) at mod_php4.c:816 #6 0x81c4ac1 in ap_child_exit_modules (p=0x8cf6578, s=0x83aa8a8) at http_config.c:1701 #7 0x81ca9c5 in clean_child_exit (code=0) at http_main.c:537 #8 0x81cc9e7 in just_die (sig=10) at http_main.c:3068 #9 0x81cca09 in usr1_handler (sig=10) at http_main.c:3078 #10 0x401cdc48 in __restore () at ../sysdeps/unix/sysv/linux/i386/sigaction.c:127 #11 0x81cab96 in accept_mutex_on_sysvsem () at http_main.c:841 #12 0x81cdd36 in child_main (child_num_arg=17) at http_main.c:4301 #13 0x81ce35c in make_child (s=0x83aa8a8, slot=17, now=1007468333) at http_main.c:4723 #14 0x81ce6d5 in perform_idle_server_maintenance () at http_main.c:4902 #15 0x81cec65 in standalone_main (argc=2, argv=0xbffffb34) at http_main.c:5139 #16 0x81cf233 in main (argc=2, argv=0xbffffb34) at http_main.c:5415 I then quit gdb and killed the high-CPU process (kill -9 28070). There were around 10 idle httpd processes at that time. The httpd process with the highest PID (#28066) then immediately started using up excessive CPU time. Doing a backtrace of it resulted in the same kind of output: 0 0x40209233 in chunk_free (ar_ptr=0x4029dd40, p=0x8cc3b98) at malloc.c:3121 #1 0x40208f9a in __libc_free (mem=0x8ccf458) at malloc.c:3023 #2 0x815765a in shutdown_memory_manager (silent=0, clean_cache=1) at zend_alloc.c:485 #3 0x80c85a5 in php_module_shutdown () at main.c:1007 #4 0x80c855c in php_module_shutdown_wrapper (sapi_globals=0x8367ba0) at main.c:972 #5 0x80c6a15 in php_child_exit_handler (s=0x83aa8a8, p=0x8cf6578) at mod_php4.c:816 #6 0x81c4ac1 in ap_child_exit_modules (p=0x8cf6578, s=0x83aa8a8) at http_config.c:1701 #7 0x81ca9c5 in clean_child_exit (code=0) at http_main.c:537 #8 0x81cc9e7 in just_die (sig=10) at http_main.c:3068 #9 0x81cca09 in usr1_handler (sig=10) at http_main.c:3078 #10 0x401cdc48 in __restore () at ../sysdeps/unix/sysv/linux/i386/sigaction.c:127 #11 0x81cab96 in accept_mutex_on_sysvsem () at http_main.c:841 #12 0x81cdd36 in child_main (child_num_arg=16) at http_main.c:4301 #13 0x81ce35c in make_child (s=0x83aa8a8, slot=16, now=1007468328) at http_main.c:4723 #14 0x81ce6d5 in perform_idle_server_maintenance () at http_main.c:4902 #15 0x81cec65 in standalone_main (argc=2, argv=0xbffffb34) at http_main.c:5139 #16 0x81cf233 in main (argc=2, argv=0xbffffb34) at http_main.c:5415 Every time I kill the CPU consuming process, the highest PID apache process takes over doing the same thing and consumes 95%+ CPU time immediately. Looking at a normal httpd process (with 0.0% CPU), the output looks like this: #0 0x4025c15e in __select () from /lib/libc.so.6 #1 0x81cab80 in accept_mutex_on_sysvsem () at http_main.c:837 #2 0x81ce35c in make_child (s=0x83aa8a8, slot=14, now=1007468327) at http_main.c:4723 #3 0x81ce6d5 in perform_idle_server_maintenance () at http_main.c:4902 #4 0x81cec65 in standalone_main (argc=2, argv=0xbffffb34) at http_main.c:5139 #5 0x81cf233 in main (argc=2, argv=0xbffffb34) at http_main.c:5415 Here is the output of a process that is active, but still not consuming hardly any CPU: #0 0x40255ab4 in __libc_read () from /lib/libc.so.6 #1 0x81ab484 in ssl_io_hook_read (fb=0x83b65e8, buf=0x83b6628 "GET /lemonnier/forum/immagini/testatina_forum.jpg HTTP/1.1\r\nAccept: */*\r\nReferer: http://www.japhost.com/lemonnier/forum/ConclusioniSecondaria/LetMinis.html\r\nAccept-Language: it\r\nAccept-Encoding: gzip"..., len=4096) at ssl_engine_io.c:339 #2 0x81e48ac in ap_hook_call_func (ap=0xbfffd864, he=0x83b30d8, hf=0x83b6570) at ap_hook.c:649 #3 0x81e3fc1 in ap_hook_call (hook=0x8336fad "ap::buff::read") at ap_hook.c:382 #4 0x81c01a0 in ap_read (fb=0x83b65e8, buf=0x83b6628, nbyte=4096) at buff.c:285 #5 0x81c1d9e in buff_read (fb=0x83b65e8, buf=0x83b6628, nbyte=4096) at buff.c:329 #6 0x81c1d48 in saferead_guts (fb=0x83b65e8, buf=0x83b6628, nbyte=4096) at buff.c:702 #7 0x81c084f in read_with_errors (fb=0x83b65e8, buf=0x83b6628, nbyte=4096) at buff.c:753 #8 0x81c0ba7 in ap_bgets (buff=0xbfffd948 "", n=8192, fb=0x83b65e8) at buff.c:906 #9 0x81d09d8 in getline (s=0xbfffd948 "", n=8192, in=0x83b65e8, fold=0) at http_protocol.c:839 #10 0x81d0cf1 in read_request_line (r=0x8d045d0) at http_protocol.c:962 #11 0x81d134e in ap_read_request (conn=0x83b9640) at http_protocol.c:1125 #12 0x81ce0c2 in child_main (child_num_arg=12) at http_main.c:4544 #13 0x81ce35c in make_child (s=0x83aa8a8, slot=12, now=1007468293) at http_main.c:4723 #14 0x81ce6d5 in perform_idle_server_maintenance () at http_main.c:4902 #15 0x81cec65 in standalone_main (argc=2, argv=0xbffffb34) at http_main.c:5139 #16 0x81cf233 in main (argc=2, argv=0xbffffb34) at http_main.c:5415 One more interesting thing is that most of the time, the high-CPU PID is not listed in an Apache /server-status list of processes. If it is listed, it has a Mode of Operation of "Waiting for connection". Lastly, sometimes only one high-CPU processes appears and consumes 95%+ CPU. Other times, multiple high-CPU processes appear. When this happens, they each consume less CPU. For instance, right now there are 3 httpd processes, each consuming 50%+ CPU time. All three process' backtraces looked the same as the first backtrace listed above (the high-CPU processes). Note that I have several additional modules included in Apache during these tests. This is a production server, so I can't do any long-term tests that do not include essential Apache mods. In addition to many of the "standard" modules, the following modules were enabled in Apache: mod_perl - static WebDAV - static mod_auth_ldap - static mod_gzip - static mod_layout - static mod_headers - static PHP - static mod_php, v4.1.0RC5, --enable-debug GD mod_ssl - static mod_jrun (JRun servlet engine) - as DSO mod_caucho (Resin servlet engine) - as DSO I've been able to duplicate this problem in both PHP 4.0.6 and PHP 4.1.0RC5 with only the bare minimum modules included. I'm pretty confident that the problem would still occur even if Apache was configured with only PHP. The backtraces do not seem to indicate any of the modules being suspicious except for PHP and the core apache. I hope this information is useful. Please let me know if there is anything else I can provide. Tauren ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/?id=14333 Edit this bug report at http://bugs.php.net/?id=14333&edit=1 -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]