PHP 4.0 Bug #9644 Updated: File Upload eats all RAM and swap space

ID: 9644 User Update by: gerard@valencia.bc.ca Old-Status: Open Status: Closed Bug Type: Reproduceable crash Description: File Upload eats all RAM and swap space After recompiling PHP with a few less options in my configure line, everything is working fine! Not sure exactly which option, when removed, got things working again. Here is the working configure line: './configure' '--with-mysql=/usr/local/mysql' '--with-mm' '--enable-ftp' '--enable-inline-optimization' '--enable-magic-quotes' '--enable-sigchild' '--enable-shmop' '--enable-sockets' '--enable-sysvshm' '--enable-sysvsem' '--enable-track-vars' '--enable-trans-sid' '--enable-versioning' '--with-gd' '--with-jpeg-dir=/usr/lib' '--with-xpm-dir=/usr/X11R6' '--with-apache=../apache_1.3.19' '--with-pgsql=/usr/local/pgsql' '--with-gettext=/usr/local' '--with-mcrypt=/usr/local' '--with-imap=/usr/local/imap-2000c' '--with-mcal' '--with-ldap' Now I can upload very large files, without any problems. Thanks! Gerard Previous Comments: --------------------------------------------------------------------------- [2001-03-17 02:53:35] gerard@valencia.bc.ca After doing some experimentation, I have realized something about Apache and PHP. According to what 'ps aux' returns, when I run apache with PHP as I have been doing normally, it has been using from 2.5%MEM - 5.0%MEM (it varies) for each child at startup. However, whenever I disable the PHP modules from Apache (by commenting off these lines in httpd.conf: 'LoadModule php4_module libexec/libphp4.so' and 'AddModule mod_php4.c'), the 'ps aux' returns 0.7%MEM per child at startup. In comparison to some other linux boxes running Apache and PHP, 2.5%MEM - 5.0%MEM is a large amount of RAM used. Could this relate in any way to the problem that I am having with file uploads on my box? --------------------------------------------------------------------------- [2001-03-12 01:29:57] gerard@valencia.bc.ca I have never used gdb before, but I have a feeling that it is not working correctly. Here are the results: root@linux:/home/install/apps/apache/apache_1.3.19# gdb /usr/local/apache/bin/httpd GNU gdb 5.0 Copyright 2000 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 "i586-pc-linux-gnu"... (gdb) run -X Starting program: /usr/local/apache/bin/httpd -X warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. Processing config directory: /usr/local/apache/conf/virtualhosts/magestudios.net/ Processing config file: /usr/local/apache/conf/virtualhosts/magestudios.net/cwolvie Processing config file: /usr/local/apache/conf/virtualhosts/magestudios.net/eeno Processing config file: /usr/local/apache/conf/virtualhosts/magestudios.net/ewang Processing config file: /usr/local/apache/conf/virtualhosts/magestudios.net/ftp Processing config file: /usr/local/apache/conf/virtualhosts/magestudios.net/g2 Processing config file: /usr/local/apache/conf/virtualhosts/magestudios.net/likwidx Processing config file: /usr/local/apache/conf/virtualhosts/magestudios.net/mail Processing config file: /usr/local/apache/conf/virtualhosts/magestudios.net/moscrop Processing config file: /usr/local/apache/conf/virtualhosts/magestudios.net/mouthoff Processing config file: /usr/local/apache/conf/virtualhosts/magestudios.net/pirachu Processing config file: /usr/local/apache/conf/virtualhosts/magestudios.net/stats Processing config file: /usr/local/apache/conf/virtualhosts/magestudios.net/web Processing config file: /usr/local/apache/conf/virtualhosts/magestudios.net/www Processing config file: /usr/local/apache/conf/virtualhosts/magestudios.net/xtracool Program received signal SIGINT, Interrupt. 0x4046c564 in read () from /lib/libc.so.6 (gdb) bt full #0 0x4046c564 in read () from /lib/libc.so.6 No symbol table info available. #1 0x81d2044 in ?? () No symbol table info available. #2 0x8084bf5 in buff_read () No symbol table info available. #3 0x8084b92 in saferead_guts () No symbol table info available. #4 0x8083612 in read_with_errors () No symbol table info available. #5 0x8083980 in ap_bgets () No symbol table info available. #6 0x8093c1b in getline () No symbol table info available. #7 0x8093efd in read_request_line () No symbol table info available. #8 0x809459e in ap_read_request () No symbol table info available. #9 0x8091104 in child_main () No symbol table info available. #10 0x8091301 in make_child () No symbol table info available. #11 0x809147c in startup_children () No symbol table info available. #12 0x8091aec in standalone_main () No symbol table info available. #13 0x809231c in main () No symbol table info available. #14 0x403e4577 in __libc_start_main () from /lib/libc.so.6 No symbol table info available. (gdb) --------------------------------------------------------------------------- [2001-03-11 16:21:25] sniper@php.net Try creating a GDB backtrace of that. 1. rm config.cache 2. Add --enable-debug to you php configure line 3. 'make clean ; make ; make install' 4. And same for apache (step 3.) 5. apachectl stop 6. gdb /path/to/httpd 7. (gdb) run -X 8. Then try that script I sent you. 9. When (if) it hangs, ctrl+c 10. (gdb) bt full 11. cut'n'paste that backtrace into this bug report. And do all this using the LATEST CVS snapshot. --Jani --------------------------------------------------------------------------- [2001-03-11 04:25:06] gerard@valencia.bc.ca I'm also getting the same problem with this script. Any script, even those that work on other systems, are giving problems on my system. --------------------------------------------------------------------------- [2001-03-10 20:04:10] sniper@php.net I can't reproduce this. Please try the following script. upload.php: <form action="upload.php" method="post" enctype="multipart/form-data" name="admin"> <input type="file" name="userfile"> <input type=submit> </form> <?php if(isset($userfile_size) && $userfile_size) { copy ($userfile, "/tmp/uploaded_file"); unlink($userfile); } ?> --------------------------------------------------------------------------- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. Full Bug description available at: http://bugs.php.net/?id=9644