ID: 14333
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: Apache related
Operating System: RH 6.2 SMP
PHP Version: 4.0.6
New Comment:
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
Previous Comments:
------------------------------------------------------------------------
[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
------------------------------------------------------------------------
[2001-12-04 02:22:02] [EMAIL PROTECTED]
Can you possibly try php-4.1.0RC5 from www.php.net/~zeev/ and make sure you do a clean
build. My guess is that your build is slightly broken. Please also try it as an static
apache module.
regards,
Derick
------------------------------------------------------------------------
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]
