[PHP-DEV] ÆóÒµ½¨Õ¾ÊÔÓÃÈ«Ãâ·Ñ,ÂúÒâ²Å¸¶¿îwww.my868.co
ÄúºÃ,¸ÐлÄúÔĶÁ±¾ÐÅ!! ÆóÒµ¼ÒÔ°Íøwww.my868.com ÊÇ׿¿Æ¿Æ¼¼ÎªÄú½¨ÔìµÄÆóÒµÍøÕ¾×Ô·þÎñϵͳ´óÐÍƽ̨,ÏÖÕýÍƳöÃâ·ÑÊÔÓ÷þÎñ,ÎÒÃÇΪÄú¹º½¨¹¦ÄÜÇ¿´óµÄÆóÒµÍøÕ¾,Èç¹ûÄúʹÓÃÖ®ºó²»ÂúÒâ,¿ÉÒÔ²»¸¶ÈκηÑÓÃ. Äú¿ÉÒÔ°ÑÆóÒµ×ÊÁϼĸøÎÒÃÇ,ÓÉÎÒÃǵŤ×÷ÈËԱΪÄú¹¹½¨ÍøÕ¾,»òÄúÖ±½Óµ½www.my868.com×¢²á,ÌîдÆóÒµ×ÊÁϺͽéÉÜ,²úÆ·ºÍ·þÎñ,Äú¿ÉÃâ·ÑÊÔÓù¦ÄÜÇ¿´óµÄÆóÒµÃÅ»§ÍøÕ¾Ò»¸öÔÂ.°üÀ¨: Ò» ¹¦ÄÜÇ¿:ÄúµÄÆóÒµÍøÕ¾¹¦ÄÜÓÐ:ÐÂÎÅ·¢²¼ÏµÍ³,²úÆ·Êý¾Ý¿â,ËÑË÷ÒýÇæ,ÔÚÏßÂÛ̳,ÁôÑÔ²¾,ÍƼö²úÆ·,ÓÑÇéÁ¬½Ó,¼ÆÊýÆ÷,¶ÀÁ¢ÓòÃû,ÆóÒµÓÊÏäµÈµÈ. ¶þ Ò×ά»¤,Äú×Ô¼º¿ÉÒÔ¹ÜÀí,¸üÐÂ,ά»¤ÄúµÄÆóÒµÍøÕ¾. Èý Ò×ʹÓÃ,ֻҪʹÓÃä¯ÀÀÆ÷¾Í¿ÉÒÔÈ«²¿²Ù×÷£¬ ËÄ ¶àÑ¡Ôñ,ÓÐ200¶àÖÖÍøÕ¾·ç¸ñ¹©ÄúÑ¡ÔñºÍ¸ü»»,Èç¹û²»ÄÜÂú×ãÄúµÄÒªÇó,ÎÒÃÇΪÄúµ¥¶À¶©ÖÆ Ãâ·ÑÊÔÓÃwww.my868.com ¹ãÖÝÊÐ׿¿Æ¿Æ¼¼ÓÐÏÞ¹«Ë¾ ФÏÈÉú(QQ 991264 [EMAIL PROTECTED]) ¹ãÖÝÊÐ º£ÖéÇø и۷ µÂ»ª½Ö ½ÄÏÃÀ¾°»¨Ô° B¶° 19E(510260) µç»°:13802965713 20-34133319 -- 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]
[PHP-DEV] Re: Bug #13816 Updated: Accessing a static HTML page crashes Apache
On Saturday, 2001-10-27 at 10:03:04 -, Bug Database wrote: ID: 13816 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: Reproducible crash Operating System: Solaris 8 SPARC PHP Version: 4.0.6 New Comment: Did you do 'apachectl stop ; apachectl start' ?? Restart won't work. I wouldn't expect restart to work. Should it? Here is a session log: Solaris8 SPARC# /opt/OCTOapache-1.3.22/bin/httpd -X [1] 14892 Solaris8 SPARC# telnet localhost 8088 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. HEAD / HTTP/1.0 HTTP/1.1 200 OK Date: Sun, 28 Oct 2001 08:54:47 GMT Server: Apache/1.3.22 (Unix) mod_perl/1.26 Last-Modified: Fri, 04 May 2001 00:00:38 GMT ETag: 398ee-5b0-3af1f126 Accept-Ranges: bytes Content-Length: 1456 Connection: close Content-Type: text/html Content-Language: en Connection closed by foreign host. Solaris8 SPARC# kill %1 Solaris8 SPARC# [1]+ Done/opt/OCTOapache-1.3.22/bin/httpd -X Solaris8 SPARC# grep -i 'module.*php' /opt/OCTOapache-1.3.22/conf/httpd.conf #-# LoadModule php4_modulelibexec/libphp4.so #-# AddModule mod_php4.c Solaris8 SPARC# # ... edit ... Solaris8 SPARC# grep -i 'module.*php' /opt/OCTOapache-1.3.22/conf/httpd.conf LoadModule php4_modulelibexec/libphp4.so AddModule mod_php4.c Solaris8 SPARC# /opt/OCTOapache-1.3.22/bin/httpd -X [1] 14933 Solaris8 SPARC# telnet localhost 8088 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. HEAD / HTTP/1.0 Connection closed by foreign host. Solaris8 SPARC# [1]+ Segmentation Fault /opt/OCTOapache-1.3.22/bin/httpd -X Solaris8 SPARC# exit -- | [EMAIL PROTECTED] |http://free.prohosting.com/~lupe | | I have challenged the entire ISO-9000 quality assurance team to a | | Bat-Leth contest on the holodeck. They will not concern us again. | | http://public.logica.com/~stepneys/joke/klingon.htm| -- 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]
[PHP-DEV] CVS Account Request: alan_dangelo
Hi, I would have access to CVS server with a personal account. I need it to give my contribute to the PHP documentation, and specially to collaborate for Italian PHP manual (and its supporting) Maintaining the documentation Translating the documentation So I would have access to phpdoc directory of server filesystem. Thanks a Lot -- 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]
[PHP-DEV] Bug #13806 Updated: PHP crashes when zlib output compression is enabled
ID: 13806 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Summary: zlib compression is broken? Status: Open Old Bug Type: Zlib Related Bug Type: Reproducible crash Old Operating System: Linux 2.4.4/glibc 2.2.2 Operating System: Linux 2.4.14-pre3/glibc 2.2.2 Old PHP Version: 4.0CVS-2001-10-24 PHP Version: 4.1.0 RC CVS-2001-10-24 New Comment: via-rihine chipset NIC dvriver seems to be fixed in 2.4.13, finanlly :) I could upgrade kernel from 2.4.4 to 2.4.14-pre3. It seems many *.c files are not modified for new asm/*.h files, yet. (It was the same, when I tried 2.4.13) Therefore, I couldn't use the same config as 2.4.4. I was using 2.4.4 kernel that comes with my distribution. Most of kernel drivers/options are compiled in or compiled as module. I'm using kernel optimized for my test PC now. Kernel may crash with other options/modules... Anyway, PHP behaves much better with newer kernel. New behavior is as follows. * PHP outputs the top part of the test script ?php phpinfo(); ? correctly. * PHP sends a lot of garbages with the test script. * Kernel seems to stop freezing. + PHP stopped complaining about many memory leaks at shutdown. Problem: * When memory limit is enabled, PHP do not terminate script execution even if it is already exhausted memory. (I get multiple error message for a single execution as attached apache error log) * PHP can't send proper phpinfo() output. * PHP segfaults with my scripts. I changed bug type form Zlib Related to Reproducible crash. If your PHP does not segfault easily, please let me know. I'll send back trace. == apache error log start == /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) == end == Previous Comments: [2001-10-27 16:24:56] [EMAIL PROTECTED] Just an update. Better procedure to reproduce this bug. I can reproduce this bug on RedHat 7.1(kernel 2.4.7) and Kondara 2.0(Kernel 2.4.4) I think this bug is *critical* and better to be fixed/workarounded before 4.1.0 release (Or disable zlib.output_compression?) Caution: This can crash your linux kernel and may crash filesystem. 1) Get 4.1.0RC CVS source 2) Copy php.ini-recommend to php.ini and enable zlib.output_compression zlib.output_compression=On 3) configure/build/install PHP 4.1.0RC './configure' \ '--with-apxs' \ '--disable-short-tags' \ '--without-mysql' \ '--without-pear' \ '--with-zlib' \ '--enable-debug' 4) Create test php script containing ?php phpinfo(); ? 5) restart httpd, diplay the test script 6) Stop httpd and check apache error log see if memory leak is reported or not. [2001-10-27 16:09:07] [EMAIL PROTECTED] This bug may be related to following bugs. http://bugs.php.net/bug.php?id=12270 http://bugs.php.net/bug.php?id=13698 [2001-10-24 08:46:19] [EMAIL PROTECTED] This is not exactly what I've reported, but if following problem is fixed, this bug may be fixed. Fixing this may fix bug #13698, also. (CGI version segfaults at shutdown) php.ini: php.ini-recommened. Only change I've made is enable ZLIB compression. If zlib compression is off, it seems working. Script: ?php phpinfo(); ? Configure: './configure' \ '--with-apxs' \
[PHP-DEV] Bug #13856: bad option in 'configure --help'
From: [EMAIL PROTECTED] Operating system: Debian Linux PHP version: 4.0.6 PHP Bug Type: *Compile Issues Bug description: bad option in 'configure --help' configure --help says: --enable-gd-native-ttfGD: Enable TrueType string function in gd but after looking in configure script I'v noticed that in fact it checks for: --enable-gd-native-tt hope You'll fix it soon greets, Adam Czysciak [EMAIL PROTECTED] -- Edit bug report at: http://bugs.php.net/?id=13856edit=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]
[PHP-DEV] Re: Bug #13856: bad option in 'configure --help'
Hej, Wlasnie otrzymalem od Ciebie taki mail I've just received such a mail from You: Temat/Subject: Bug #13856: bad option in 'configure --help' Data/Date: 28 Oct 2001 12:34:24 - To jest potwierdzenie generowane automatycznie i oznacza tylko tyle, ze Twoj mail dotarl w 100%. This is just a confirmation generated automatically. It means that your mail has been successfully delivered. -- Zycze milego dnia, Have a nice day, Adam vel acc [EMAIL PROTECTED] -- 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]
[PHP-DEV] Bug #13806 Updated: zlib compression is broken?
ID: 13806 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Reproducible crash Operating System: Linux 2.4.14-pre3/glibc 2.2.2 PHP Version: 4.1.0 RC CVS-2001-10-24 New Comment: Upgraded from apache 1.3.20 to 1.3.22. httpd exited with status code 01 while running under gdb. (gdb) run -X Starting program: /usr/sbin/httpd -X Program exited with code 01. (gdb) Previous Comments: [2001-10-28 07:29:53] [EMAIL PROTECTED] via-rihine chipset NIC dvriver seems to be fixed in 2.4.13, finanlly :) I could upgrade kernel from 2.4.4 to 2.4.14-pre3. It seems many *.c files are not modified for new asm/*.h files, yet. (It was the same, when I tried 2.4.13) Therefore, I couldn't use the same config as 2.4.4. I was using 2.4.4 kernel that comes with my distribution. Most of kernel drivers/options are compiled in or compiled as module. I'm using kernel optimized for my test PC now. Kernel may crash with other options/modules... Anyway, PHP behaves much better with newer kernel. New behavior is as follows. * PHP outputs the top part of the test script ?php phpinfo(); ? correctly. * PHP sends a lot of garbages with the test script. * Kernel seems to stop freezing. + PHP stopped complaining about many memory leaks at shutdown. Problem: * When memory limit is enabled, PHP do not terminate script execution even if it is already exhausted memory. (I get multiple error message for a single execution as attached apache error log) * PHP can't send proper phpinfo() output. * PHP segfaults with my scripts. I changed bug type form Zlib Related to Reproducible crash. If your PHP does not segfault easily, please let me know. I'll send back trace. == apache error log start == /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) == end == [2001-10-27 16:24:56] [EMAIL PROTECTED] Just an update. Better procedure to reproduce this bug. I can reproduce this bug on RedHat 7.1(kernel 2.4.7) and Kondara 2.0(Kernel 2.4.4) I think this bug is *critical* and better to be fixed/workarounded before 4.1.0 release (Or disable zlib.output_compression?) Caution: This can crash your linux kernel and may crash filesystem. 1) Get 4.1.0RC CVS source 2) Copy php.ini-recommend to php.ini and enable zlib.output_compression zlib.output_compression=On 3) configure/build/install PHP 4.1.0RC './configure' \ '--with-apxs' \ '--disable-short-tags' \ '--without-mysql' \ '--without-pear' \ '--with-zlib' \ '--enable-debug' 4) Create test php script containing ?php phpinfo(); ? 5) restart httpd, diplay the test script 6) Stop httpd and check apache error log see if memory leak is reported or not. [2001-10-27 16:09:07] [EMAIL PROTECTED] This bug may be related to following bugs. http://bugs.php.net/bug.php?id=12270 http://bugs.php.net/bug.php?id=13698 [2001-10-24 08:46:19] [EMAIL PROTECTED] This is not exactly what I've reported, but if following problem is fixed, this bug may be fixed. Fixing this may fix bug #13698, also. (CGI version segfaults at shutdown) php.ini: php.ini-recommened. Only change I've made is enable
Re: [PHP-DEV] Massive memory leak? (4.1.0RC1)
Jani Taskinen wrote: Just a little warning: This will lock your machine. I just spend a while fixing the damages caused by the crash.. (Maybe I should be using something else than ext2 ?) I upgraded to Apache 1.3.22/kernel 2.4.14-pre3 (with much less options/modules compare to kernel 2.4.4) It seems system works much better with newer kernel. It doesn't freeze/crash at least. However, problem still exists. Please refer to http://bugs.php.net/bug.php?id=13806 for details. -- Yasuo Ohgaki -- 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]
[PHP-DEV] Re: Bug #13856 Updated: bad option in 'configure --help'
Hej, Wlasnie otrzymalem od Ciebie taki mail I've just received such a mail from You: Temat/Subject: Bug #13856 Updated: bad option in 'configure --help' Data/Date: 28 Oct 2001 14:20:30 - To jest potwierdzenie generowane automatycznie i oznacza tylko tyle, ze Twoj mail dotarl w 100%. This is just a confirmation generated automatically. It means that your mail has been successfully delivered. -- Zycze milego dnia, Have a nice day, Adam vel acc [EMAIL PROTECTED] -- 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]
[PHP-DEV] Bug #13856 Updated: bad option in 'configure --help'
ID: 13856 Updated by: derick Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: *Compile Issues Operating System: Debian Linux PHP Version: 4.0.6 New Comment: Already fixed in CVS. Derick Previous Comments: [2001-10-28 07:34:24] [EMAIL PROTECTED] configure --help says: --enable-gd-native-ttfGD: Enable TrueType string function in gd but after looking in configure script I'v noticed that in fact it checks for: --enable-gd-native-tt hope You'll fix it soon greets, Adam Czysciak [EMAIL PROTECTED] Edit this bug report at http://bugs.php.net/?id=13856edit=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]
[PHP-DEV] Bug #13806 Updated: zlib compression is broken?
ID: 13806 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Reproducible crash Operating System: Linux 2.4.14-pre3/glibc 2.2.2 PHP Version: 4.1.0 RC CVS-2001-10-24 New Comment: Problem is appearent if output is larger than output buffer size. httpd exits with code 01 with following script (No output) ?php for ($i=0; $i 1024; $i++) echo 'abcd'; ? but it not with (Output is correct) ?php for ($i=0; $i 1023; $i++) echo 'abcd'; ? It exits with code 01 with more complex script w/o output, though. Previous Comments: [2001-10-28 08:50:56] [EMAIL PROTECTED] Upgraded from apache 1.3.20 to 1.3.22. httpd exited with status code 01 while running under gdb. (gdb) run -X Starting program: /usr/sbin/httpd -X Program exited with code 01. (gdb) [2001-10-28 07:29:53] [EMAIL PROTECTED] via-rihine chipset NIC dvriver seems to be fixed in 2.4.13, finanlly :) I could upgrade kernel from 2.4.4 to 2.4.14-pre3. It seems many *.c files are not modified for new asm/*.h files, yet. (It was the same, when I tried 2.4.13) Therefore, I couldn't use the same config as 2.4.4. I was using 2.4.4 kernel that comes with my distribution. Most of kernel drivers/options are compiled in or compiled as module. I'm using kernel optimized for my test PC now. Kernel may crash with other options/modules... Anyway, PHP behaves much better with newer kernel. New behavior is as follows. * PHP outputs the top part of the test script ?php phpinfo(); ? correctly. * PHP sends a lot of garbages with the test script. * Kernel seems to stop freezing. + PHP stopped complaining about many memory leaks at shutdown. Problem: * When memory limit is enabled, PHP do not terminate script execution even if it is already exhausted memory. (I get multiple error message for a single execution as attached apache error log) * PHP can't send proper phpinfo() output. * PHP segfaults with my scripts. I changed bug type form Zlib Related to Reproducible crash. If your PHP does not segfault easily, please let me know. I'll send back trace. == apache error log start == /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) == end == [2001-10-27 16:24:56] [EMAIL PROTECTED] Just an update. Better procedure to reproduce this bug. I can reproduce this bug on RedHat 7.1(kernel 2.4.7) and Kondara 2.0(Kernel 2.4.4) I think this bug is *critical* and better to be fixed/workarounded before 4.1.0 release (Or disable zlib.output_compression?) Caution: This can crash your linux kernel and may crash filesystem. 1) Get 4.1.0RC CVS source 2) Copy php.ini-recommend to php.ini and enable zlib.output_compression zlib.output_compression=On 3) configure/build/install PHP 4.1.0RC './configure' \ '--with-apxs' \ '--disable-short-tags' \ '--without-mysql' \ '--without-pear' \ '--with-zlib' \ '--enable-debug' 4) Create test php script containing ?php phpinfo(); ? 5) restart httpd, diplay the test script 6) Stop httpd and check apache error log see if memory leak is reported or not. [2001-10-27 16:09:07] [EMAIL PROTECTED] This bug may be
[PHP-DEV] Bug #13176 Updated: Headers output in HTML body.
ID: 13176 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Old Bug Type: Output Control Bug Type: *General Issues Operating System: RedHat Linux 6.0(ish) PHP Version: 4.0.6 New Comment: Bogusing this report. Asked the user to submit new report with a proper password. (This one had empty passwd) --Jani Previous Comments: [2001-10-03 18:01:30] [EMAIL PROTECTED] user feedback (he didn't set the password for this report): --- I've just done a compile and test of the latest snapshot of PHP from http://snaps.php.net/ Config: ./configure --with-mysql=/usr --with-gd --enable-force-cgi-redirect --with-config-file-path=/etc/php4/cgi/ --with-imap --enable-ftp --with-openssl --with-kerberos=/usr/kerberos --with-jpeg=/usr --with-pdflib Archive: php4-20011003 Without lines loading extensions in php.ini, it's okay, but with one loading mysql.so, I get: X-Powered-By: PHP/4.0.8-dev Content-type: text/html In the HTML, rather than as headers. Looks like something's outputting a \n before sending those headers. Using headers_sent() reports that they have not been sent at the very start of php code which illustrates this problem, as you might expect. So it's probably something in the header sending/preparation routines being silly... Also, it occurs to me that perhaps this bug is caused by trying to load a module in that's already compiled into the main php executable (we run it in CGI mode, btw...) [2001-10-02 19:38:08] [EMAIL PROTECTED] No feedback. [2001-09-06 11:47:31] [EMAIL PROTECTED] Does this happen with certain script? Do you use ob_* functions? Is output_buffering on/off in your php.ini? Is output_handler set in your php.ini? Is zlib.output_compression set in your php.ini? Does this happen with latest CVS snapshot from http://snaps.php.net/ ? --Jani [2001-09-06 11:16:02] [EMAIL PROTECTED] Hi, Sorry if this is a duplicate (I've checked and it doesn't look like it though), or me being silly... We've had this problem in versions 4.0.4pl1 through to PHP4.0.6, running as a CGI through apache (various versions between 1.3.3 and 1.3.12 I think...) using the setup described in the PHP docs. Configure options approximately (they have changed through various versions of PHP I've compiled up) ./configure --with-mysql --with-gd --enable-force-cgi-redirect --with-config-file-path=/etc/php4/cgi/ --with-imap --enable-ftp --with-openssl --with-kerberos=/usr/kerberos --with-zlib-dir=/usr/lib --with-jpeg=/usr --with-tiff=/usr The systems that PHP are running on are some 20 patched-up RH6.0 machines, all of which exhibit this symptom. It can be got around by disabling loading of any dynamic modules, even dynamic modules which don't exist on the server cause this problem if you attempt to load them with an extension= line in the relevant php.ini. I'd previously assumed it to be specific to the mysql module or similar, but it seems that it's the module loading routine which is erroneously outputting a newline or two to indicate the end of the HTTP headers before it should do, because if you try to load a module that doesn't exist it still does the same. I'm reporting it now because I have just got a new bit of information, and nobody could have reported it yet otherwise I assume you would have solved it in php-4.0.5. Yours, Kev. PS. Some system info. Just ask if you need more that this... Linux version 2.2.13 ([EMAIL PROTECTED]) (gcc version egcs-2.91.60 19981201 (egcs-1.1.1 release)) #1 SMP Mon Dec 13 01:50:21 GMT 1999 Red Hat Linux release 6.0 (Hedwig) Server version: Apache/1.3.9 (Unix) Server built: Dec 13 1999 17:18:12 Edit this bug report at http://bugs.php.net/?id=13176edit=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]
[PHP-DEV] Bug #13848 Updated: transparent sessions not w3c compliant
ID: 13848 Updated by: sniper Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: URL related Operating System: Linux PHP Version: 4.0.4pl1 New Comment: This applies to PHP 4.0.6 and above. So update first. --Jani Previous Comments: [2001-10-27 09:15:13] [EMAIL PROTECTED] Not a bug, see this part from php.ini-recommended: ; The separator used in PHP generated URLs to separate arguments. ; Default is . ;arg_separator.output = amp; [2001-10-27 09:08:38] [EMAIL PROTECTED] transparent sessions don't appear to be w3c compliant, in that when a url is not cookied, it appears as, eg a href=index.php?id=xyzPHPSESSION=3982982 where it should be a href=index.php?id=xyzamp;PHPSESSION=3982982 see http://www.htmlhelp.com/tools/validator/problems.html#amp Edit this bug report at http://bugs.php.net/?id=13848edit=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]
[PHP-DEV] Re: Package extension proposal
Hi Stanislav, Below is the proposal for PHP packaging extension. The intentions is for PHP to have the package system kind of like what Perl and other languanges have. The comments and suggestions are most welcome, as usual. Especially the experience with packaging system from other languages. +1000 for this proposal. It's very useful and makes things very clear and easy to use. package_load(Name) What about import(Name) and import name short, clean and descriptive, isn't it? Technology: == Package is located and loaded in the following way: 1. First, the package location name is determined. If the name does not contain :: signs, the package location name is the package name. If the package name contains ::, each :: component is a subdirectory, i.e. Foo::Bar::Baz produces the location name of Foo/Bar/Baz (just like in Perl). How about using the . as a seperator? Ok, you can not use filenames with more than one dot in them, but I think that's an advantage even if it looks like a drawback. The packaged files are clear structured Name.Extension and not name.anothername.something.extension. This will also account for OS's that don't like moe than one dots in fnames and the cdrom ISO conventions etc. Package: Foo::Bar Version: 3.14.15 Requires: PEAR Requires: DB::MySQL Files: boobar.php boo.inc classes/class.A.inc classes/class.B.inc Looks good, but as Stig said, pear does already have a xml description file. I find this very convinient and useful. What performance concerns: PHP could create a php-version of the package.xml on first load call if xml parsing at runtime is to slow. I'm looking forward to have such an extension soon. This is real benefit to the coders world. Andi -- www.thyrell.com -- 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]
[PHP-DEV] Bug #5360 Updated: Session not holding over.
ID: 5360
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Session related
Operating System: Red Hat Linux 6.1
PHP Version: 4.0.1pl2
New Comment:
POST is also supported. If you enable transparent-session-id propagation, PHP will
include a input type=hidden with the session name and id, and thus will work with
both POST and GET.
Where in the manual does it say that post isn't supported?
See 13841 for future updates about this problem, because it seems it's the same
problem after all.
Previous Comments:
[2000-07-27 21:04:20] [EMAIL PROTECTED]
reading the manual, php sessions support
a) GET
b) cookies
but if you want to use POST you can extract that post_var on another page and use
session_name() then
read the manual on session handling
[2000-07-07 19:59:10] [EMAIL PROTECTED]
I've tried this with IE and Netscape and it doesn't work:
http://216.235.251.8/login.phtml
TO USE: Initially you can just enter in anything you want. It will post to itself, the
session is started and the phpsessid variable is blank.
Then put anything else in the user and password fields and submit again. You'll see
the phpsessid populated with the previous ID but when the session_start is called, a
new ID is created and in the middle when I echo SID; it displays the string. The SID
macro is working and outputing information even though the cookie is being set,
contrary to the
documentation.
How do I know that the cookie is being set? Well, I look in my cookies.txt file and
find the cookie listed. (some may need to quit the browser before seeing the cookie in
the file).
[2000-07-04 17:33:17] [EMAIL PROTECTED]
This is a baffling problem. Perhaps I'm doing something wrong but I believe I'm doing
everything correct.
Here is an example script of what I'm talkinng about please save this in a file called
login.phtml or change the FORM tag to reflect the filename you choose.:
-
?
session_start();
if ($login) {
echo Posted Variable (echo \$PHPSESSID): . $PHPSESSID . BR;
//session_id($PHPSESSID);
echo session started (echo session_id()): . session_id() . BR;
session_register(user,pass);
echo Variable Registered in session (echo session_id()): . session_id() .
BR;
}
?HTML
HEAD
TITLELogin Testing/TITLE
/HEAD
BODY BGCOLOR=#FF
BRBR
Session display using echo SID;:? echo SID; ?BRBR
FORM METHOD=POST ACTION=login.phtml
form field populated using lt;? echo session_id(); ?gt;BR
Posting Variable: PHPSESSID: INPUT TYPE=TEXT NAME=PHPSESSID VALUE=? echo
session_id(); ? WIDTH=50BR
USER: INPUT TYPE=text NAME=userBR
PASS: INPUT TYPE=text NAME=passBR
INPUT TYPE=SUBMIT VALUE=login NAME=loginBR
/FORM
/BODY
/HTML
In this example, when session_start() is called, a new session variable is created. If
I you uncomment the line that forces the session ID back to what it should be, the
variables get registered in the proper session but when you echo SID it reverts to
the previous session and the $PHPSESSID is updated also to the new, incorrect,
session. This was done by testing under an SSL connection because this is where I
need to use it.
The installation is Apache 1.3.12+mod_ssl
One Curious thing:
If I change it the method to GET then this is what happens. at the first
initialization of the session it creates it, then when you submit the form, a new
session is created. But every post after that retains the session ID. Will this only
work via the GET method? I sincerely hope not because I need to keep the password
hidden.
Edit this bug report at http://bugs.php.net/?id=5360edit=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]
[PHP-DEV] Bug #13842 Updated: Member variables in parent and child classes overwrite each other
ID: 13842
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Bogus
Bug Type: Class/Object related
Operating System: Windows NT 5.0 build 2195
PHP Version: 4.0.6
New Comment:
Alle class vars are public, in a future PHP (5?) there will also be private object
vars.
Until then, object vars of children and parents are simply the same, and thus
overwrite eachother. This is intended behavior.
Not a bug.
Previous Comments:
[2001-10-27 01:37:46] [EMAIL PROTECTED]
Works fine for me with latest CVS. Please try the
development build from http://www.php4win.com/
--Jani
[2001-10-26 17:52:30] [EMAIL PROTECTED]
I'm not all that familiar with PHP, so it's possible I haven't understood something
that should be obvious, or have mistyped something. But assuming that's not the case:
To my eye this makes using someone else's classes via inheritence a wee bit dangerous,
and makes using inheritence at all somewhat problematic since changing a class that
exists in an inheritence makes one liable to create subtle bugs in code that one has
not modified - which defeats one of the (possibly the most) principal purposes of OO.
If I could make a suggestion: support of 'private' and 'public' for member variables
might be a good thing. Especially if access defaulted to 'private' and that meant that
the variable was only visible to the immediate class.
Using the CGI binary without modification running on Microsoft-IIS/5.0 I used the
following test script:
html
head
titleInheritence Bug/title
/head
body
?php
//=
// NOTE:
// Bad behaviour if C2 extends C1, Correct if C2 extends C1_1
class C2 extends C1_1
{
var $m_sMe = C2; // ERROR: this
overwrites parent
var $m_sIniter = ;
function C2( $sIniter=)
{
$this-m_sIniter = $sIniter;// OK - by defn
parent::C1( $this-m_sMe); // OK - the way to do
it
}
function WhoIsIt()
{
printf( C2::WhoIsIt() : This is: . $this-m_sMe .
br\n);
printf( Inited by: . $this-m_sIniter . br\n);
parent::WhoIsIt();
}
}
//=
class C1_1
{
var $m_sMe_1 = C1;
var $m_sIniter_1 = ;
function C1( $sIniter=)
{
print( (OK)br\n);
$this-m_sIniter_1 = $sIniter;
}
function WhoIsIt()
{
printf( C1::WhoIsIt() : This is: . $this-m_sMe_1 .
br\n);
printf( Inited by: . $this-m_sIniter_1 . br\n);
}
function ResetBase()
{
$this-m_sMe_1 = C1;
printf( C1::ResetBase() : This is: . $this-m_sMe_1 .
br\n);
printf( Inited by: . $this-m_sIniter_1 . br\n);
}
}
//=
class C1
{
var $m_sMe = C1;
var $m_sIniter = ;
function C1( $sIniter=)
{
print( (Bad)br\n);
$this-m_sIniter = $sIniter;// ERROR: this overwrites
child's value
}
function WhoIsIt()
{
printf( C1::WhoIsIt() : This is: . $this-m_sMe .
br\n);
printf( Inited by: . $this-m_sIniter . br\n);
}
function ResetBase()
{
$this-m_sMe = C1;
printf( C1::ResetBase() : This is: . $this-m_sMe .
br\n);
printf( Inited by: . $this-m_sIniter . br\n);
}
}
//=
$test = new C2( Doug);
$test-WhoIsIt();
//$test-ResetBase();
?
p
In case there is a platform dependency, this is what I consider correct output:br
pre
C2::WhoIsIt() : This is: C2
Inited by: Doug
C1::WhoIsIt() : This is: C1
Inited by: C2
/pre
/p
/body
/html
Edit this bug report at http://bugs.php.net/?id=13842edit=1
--
PHP Development
[PHP-DEV] Bug #13857: Attempting to load shared modules causes header problems.
From: [EMAIL PROTECTED] Operating system: RedHat 6.1 (ish) PHP version: 4.0.6 PHP Bug Type: Dynamic loading Bug description: Attempting to load shared modules causes header problems. At Jani's request, recreating this bug report with a password so I can edit it directly... This condition has been present in PHP's 4.0.4pl1 through to snapshot version php4-20011003 Basically what happens is that whenever we use an extension=module.so line in our php.ini, we see the headers generated by the expose_php = yes configuration condition, and the Content-type:, and any session-related headers in the body content of a web page generated by PHP. The only way to make this go away is of course to not use loadable modules, which is not exactly optimal for us. It happens with a range of modules, basically every one that we have tried. It also happens with extension=non-existent-module.so. However as Jani rightly said, there would be complaints all over the place about this one if it happened to everyone, so it must be dependant on some other factor, ie. the OS. There's some background information following this... Oh, our config has been varied considerably through the various releases, due to customer demand for new features to be compiled in, but the latest version we've been using is: ./configure --with-mysql=/usr --with-gd --enable-force-cgi-redirect --with-config-file-path=/etc/php4/cgi/ --with-imap --enable-ftp --with-openssl --with-kerberos=/usr/kerberos --with-jpeg=/usr --with-pdflib --with-domxl --with-wbmp --with-zlib=/usr --with-bz2 No doubt you'll email me if you need more info ;-) K. PS. For reference, because it's probably useful, this used to be Bug #13176 Updated: Headers output in HTML body., but I didn't put in a password, so I had to email updates, hence the new bug report. It doesn't seem to be related to extension=module.so where the module is already compiled in explicitly, or where it isn't. It also doesn't seem to be related to a specific module. I think you're right, though. I think it's probably a problem specific to PHP on a certain (RedHat) architecture. The best way to solve it looks to be to consider the mechanism involved in loading the modules, and seeing what code external to PHP is called, and what it might be doing that's nasty. So, here's what our ld.so is: [root@fred cgi]# rpm -qi ld.so-1.9.5-8 Name: ld.soRelocations: (not relocateable) Version : 1.9.5 Vendor: Red Hat Software Release : 8 Build Date: Tue Aug 25 10:55:21 1998 Install date: Wed Jan 13 17:50:46 1999 Build Host: porky.redhat.com Group : Libraries Source RPM: ld.so-1.9.5-8.src.rpm Size: 251943 License: BSD Packager: Red Hat Software [EMAIL PROTECTED] Summary : Shared library configuration tool and old dynamic loader Description : This package contains the shared library configuration tool, ldconfig, which is required by many packages. It also includes the shared library loader and dynamic loader for Linux libc 5. Also, it might be of import that we are compiling on a different machine to that which we are deploying the PHP binary (for security etc., we don't have compilers on our world-facing web servers, and hence have to compile elsewhere). But I don't know for sure. This is all rather in depth code stuff for me... [2001-09-06 11:47:31] [EMAIL PROTECTED] Does this happen with certain script? All scripts for all of our customers it seems, until we remove all dynamic module loading in their php.ini. This is odd. Does plain vanilla php.ini-dist copied to php.ini work?? Does this happen with latest CVS snapshot from http://snaps.php.net/ ? Haven't had a chance to test this yet, but it's happened in every version from 4.0.4pl1 through to 4.0.6 so far... Please try the snapshot. There have been so many fixes and at least two of them were module loading related. --Jani -- Edit bug report at: http://bugs.php.net/?id=13857edit=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]
[PHP-DEV] Bug #13848 Updated: transparent sessions not w3c compliant
ID: 13848 Updated by: jeroen Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: URL related Operating System: Linux PHP Version: 4.0.4pl1 New Comment: Shouldn't amp; be made the default? Since that's the only correct thing, and at least since HTML 2.0 amp;-style quoting was required. Or are there browsers doing it wrong? Bad browsers in that case, but it could be a reason to not change the default: Apache for examples has also some workarounds in their default httpd.conf for buggy browsers. Previous Comments: [2001-10-28 10:36:50] [EMAIL PROTECTED] This applies to PHP 4.0.6 and above. So update first. --Jani [2001-10-27 09:15:13] [EMAIL PROTECTED] Not a bug, see this part from php.ini-recommended: ; The separator used in PHP generated URLs to separate arguments. ; Default is . ;arg_separator.output = amp; [2001-10-27 09:08:38] [EMAIL PROTECTED] transparent sessions don't appear to be w3c compliant, in that when a url is not cookied, it appears as, eg a href=index.php?id=xyzPHPSESSION=3982982 where it should be a href=index.php?id=xyzamp;PHPSESSION=3982982 see http://www.htmlhelp.com/tools/validator/problems.html#amp Edit this bug report at http://bugs.php.net/?id=13848edit=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]
[PHP-DEV] Bug #13850 Updated: CASE within SWITCH may crash apache
ID: 13850
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Status: Feedback
Old Bug Type: Documentation problem
Bug Type: Scripting Engine problem
Operating System: Windows 2000 Pro SP1
PHP Version: 4.0.4
New Comment:
Reclassified.
Please also be more specific on the error, are you saying it crashes? What's the html
output? Could you post the URL here?
Previous Comments:
[2001-10-28 11:17:46] [EMAIL PROTECTED]
Unable to reproduce with 4.0.3pl1 or latest dev on linux, and also I can't reproduce
on 4.0.4pl1 on windows.
I get (correctly) a parse error on (incorrectly, but known 'feature') the line with
the switch.
Please try to upgrade, use at least 4.0.4pl1 and not 4.0.4.
[2001-10-27 13:12:45] [EMAIL PROTECTED]
The following script raised an error in apache (1.3.19)permantly. The error message
describes an Memory Write Problem.
The reason are the operators after CASE. If they are removed
the script runs without errors.
The error can be reproduced.
I've tried it with different activated modules in PHP but the problem persists.
I think it should be better to put this into the documentation.
?php
$foo = 20
switch($foo)
{
case 50:
echo Less than 50;
break;
case 50 100
echo Between 50 and 100;
break;
default:
echo 100;
break;
}
?
Edit this bug report at http://bugs.php.net/?id=13850edit=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]
[PHP-DEV] Bug #13852 Updated: zlib file reading functions not working in Apache Module version
ID: 13852
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: Zlib Related
Operating System: Windows 2000
PHP Version: 4.0.4pl1
New Comment:
Probably not a bug (cgi does work, so very unlikely to be a bug in PHP or zlib). Ask
support questions on http://www.php.net/support.php , or reopen if I'm wrong.
Try this:
Please check the location of your php.ini, that you're editing the right one. (check
wether modifications show up in a phpinfo() page).
And check your error reporting level, set it to E_ALL (error_reporting(E_ALL); before
anything). My guess is it's giving undefined function errors.
Previous Comments:
[2001-10-27 16:58:01] [EMAIL PROTECTED]
most of the zlib file reading functions, like gzfile,gzread,gzpassthru,gzgetc do not
work in the Apache Module version of php.
the function returns no value - without outputting any error or warning; sometimes the
webserver crashes.
when i switched php to run as cgi everything works as expected.
don't know if this has been fixed, couldn't find an entry in the bugfinder.
phil.
running extensions:
extension=php_zlib.dll
extension=php_sablot.dll
extension=php_gd.dll
extension=php_pdf.dll
demo script (test.gz would be ascii text):
$log = gzfile('test.gz');
foreach ($log as $l) echo $lbr;
Edit this bug report at http://bugs.php.net/?id=13852edit=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]
[PHP-DEV] Re: Bug #13842 Updated: Member variables in parent and child classes overwrite each other
Pleaes use the web interface for updating bugs!
I missed this mail until now.
--Jeroen
- Original Message -
From: Doug Plant [EMAIL PROTECTED]
Newsgroups: php.dev
To: [EMAIL PROTECTED]
Sent: Sunday, October 28, 2001 4:38 AM
Subject: Re: Bug #13842 Updated: Member variables in parent and child
classes overwrite each other
Hi,
Thanks for the reply. Still looks bad.
My mistake, but I left the script in it's good configuration. If you
change the line:
class C2 extends C1_1
To:
class C2 extends C1
the the bad behaviour is shown. I left the line in the former state.
Doug
From: Bug Database [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Bug #13842 Updated: Member variables in parent and child classes
overwrite each other
Date: 27 Oct 2001 05:37:46 -
ID: 13842
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: Class/Object related
Operating System: Windows NT 5.0 build 2195
PHP Version: 4.0.6
New Comment:
Works fine for me with latest CVS. Please try the
development build from http://www.php4win.com/
--Jani
Previous Comments:
[2001-10-26 17:52:30] [EMAIL PROTECTED]
I'm not all that familiar with PHP, so it's possible I haven't understood
something that should be obvious, or have mistyped something. But
assuming
that's not the case:
To my eye this makes using someone else's classes via inheritence a wee
bit
dangerous, and makes using inheritence at all somewhat problematic since
changing a class that exists in an inheritence makes one liable to create
subtle bugs in code that one has not modified - which defeats one of the
(possibly the most) principal purposes of OO.
If I could make a suggestion: support of 'private' and 'public' for
member
variables might be a good thing. Especially if access defaulted to
'private' and that meant that the variable was only visible to the
immediate class.
Using the CGI binary without modification running on Microsoft-IIS/5.0
I
used the following test script:
html
head
titleInheritence Bug/title
/head
body
?php
file://=
// NOTE:
// Bad behaviour if C2 extends C1, Correct if C2 extends C1_1
class C2 extends C1_1
{
var $m_sMe = C2; // ERROR: this overwrites parent
var $m_sIniter = ;
function C2( $sIniter=)
{
$this-m_sIniter = $sIniter; // OK - by defn
parent::C1( $this-m_sMe); // OK - the way to do it
}
function WhoIsIt()
{
printf( C2::WhoIsIt() : This is: . $this-m_sMe . br\n);
printf( Inited by: . $this-m_sIniter . br\n);
parent::WhoIsIt();
}
}
file://=
class C1_1
{
var $m_sMe_1 = C1;
var $m_sIniter_1 = ;
function C1( $sIniter=)
{
print( (OK)br\n);
$this-m_sIniter_1 = $sIniter;
}
function WhoIsIt()
{
printf( C1::WhoIsIt() : This is: . $this-m_sMe_1 . br\n);
printf( Inited by: . $this-m_sIniter_1 . br\n);
}
function ResetBase()
{
$this-m_sMe_1 = C1;
printf( C1::ResetBase() : This is: . $this-m_sMe_1 . br\n);
printf( Inited by: . $this-m_sIniter_1 . br\n);
}
}
file://=
class C1
{
var $m_sMe = C1;
var $m_sIniter = ;
function C1( $sIniter=)
{
print( (Bad)br\n);
$this-m_sIniter = $sIniter; // ERROR: this overwrites child's value
}
function WhoIsIt()
{
printf( C1::WhoIsIt() : This is: . $this-m_sMe . br\n);
printf( Inited by: . $this-m_sIniter . br\n);
}
function ResetBase()
{
$this-m_sMe = C1;
printf( C1::ResetBase() : This is: . $this-m_sMe . br\n);
printf( Inited by: . $this-m_sIniter . br\n);
}
}
file://=
$test = new C2( Doug);
$test-WhoIsIt();
file://$test-ResetBase();
?
p
In case there is a platform dependency, this is what I consider correct
output:br
pre
C2::WhoIsIt() : This is: C2
Inited by: Doug
C1::WhoIsIt() : This is: C1
Inited by: C2
/pre
/p
/body
/html
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at
http://bugs.php.net/?id=13842edit=2
_
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
--
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]
[PHP-DEV] Suggestion RFC: Bug db mails
Hi, Suggestion: set the From: of bug-mails to [EMAIL PROTECTED], and put a autoresponer over there asking the user again to use the web interface in stead of replying, and possibly don't give the php-dev mail at all, or as 'only for ...'. --Jeroen -- 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]
[PHP-DEV] Bug #13855 Updated: Undefined Symbol: mysql_module_entry when compiling with mysql option specified
ID: 13855 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: Compile Failure Operating System: Linux 2.4.2 PHP Version: 4.0.6 New Comment: There is already one report about Mysql 4.0 not working with current PHP versions. And it's being worked on so this report is not necessary. Next time read the instructions about submitting reports before submitting any. --Jani Previous Comments: [2001-10-28 01:18:51] [EMAIL PROTECTED] When trying to compile Apache 1.3.22 with the PHP library, the Apache compilation fails with the following error: Undefined symbol: mysql_module_entry This occurs _only_ if you try to use the MySQL libraries by specifying: --with-mysql=/usr/local/mysql in the PHP configure script. If you use --with-mysql without any arguments, Apache compiles properly. There is a note on the MySQL mailing list about this: http://lists.mysql.com/cgi-ez/ezmlm-cgi?1:mss:88933 The message claims that this is a PHP problem because MySQL does not define this symbol. System: Redhat 7.1 Linux 2.4.2 Compiler: GCC 2.96 (unfortunately) Edit this bug report at http://bugs.php.net/?id=13855edit=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]
[PHP-DEV] Bug #13816 Updated: Accessing a static HTML page crashes Apache
ID: 13816 Updated by: sniper Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Reproducible crash Operating System: Solaris 8 SPARC PHP Version: 4.0.6 New Comment: Try removing mod_perl and see if it works then. --Jani Previous Comments: [2001-10-27 06:03:04] [EMAIL PROTECTED] Did you do 'apachectl stop ; apachectl start' ?? Restart won't work. --Jani [2001-10-24 13:17:56] [EMAIL PROTECTED] Config: Apache 1.3.22, mod_perl 1.26 with perl 5.6.1, PHP 4.0.6, Sun E250, Solaris 8 PHP configured with apxs like this: ./configure --verbose --prefix=/opt/OCTOapache-1.3.22 --datadir=/opt/OCTOapache-1.3.22/lib --exec-prefix=/opt/OCTOapache-1.3.22 --libexecdir=/opt/OCTOapache-1.3.22/helpers --localstatedir=/opt/OCTOapache-1.3.22/lib --enable-sysvsem -enable-sysvshm --with-ndbm --with-yp --with-ldap=/opt/local/sparc --with-mysql=/opt/OCTOmysql --enable-shmop --with-exec-dir=/opt/OCTOapache-1.3.22/safe-exec --with-config-file-path=/opt/OCTOapache-1.3.22/conf/php3.ini --enable-safe-mode --with-apxs=/opt/OCTOapache-1.3.22/bin/apxs Just doing a HEAD request on / crashes Apache if libphp4.so is loaded: LoadModule php4_modulelibexec/libphp4.so AddModule mod_php4.c telnet localhost 8088 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. HEAD / HTTP/1.0 Connection closed by foreign host. This is the tail of the systemcall trace from truss: 11140: stat64(/opt/OCTOapache-1.3.22/htdocs/index.html.ru.iso-ru, 0x002E3908) = 0 11140: stat64(/opt/OCTOapache-1.3.22/htdocs/index.html.ru.koi8-r, 0x002E3908) = 0 11140: stat64(/opt/OCTOapache-1.3.22/htdocs/index.html.ru.ucs2, 0x002E3908) = 0 11140: stat64(/opt/OCTOapache-1.3.22/htdocs/index.html.ru.ucs4, 0x002E3908) = 0 11140: stat64(/opt/OCTOapache-1.3.22/htdocs/index.html.ru.utf8, 0x002E3908) = 0 11140: getdents64(7, 0x0028C018, 1048) = 128 11140: stat64(/opt/OCTOapache-1.3.22/htdocs/index.html.se, 0x002E3908) = 0 11140: stat64(/opt/OCTOapache-1.3.22/htdocs/index.html.zh.Big5, 0x002E7908) = 0 11140: getdents64(7, 0x0028C018, 1048) = 0 11140: close(7)= 0 11140: stat64(/opt/OCTOapache-1.3.22/htdocs/index.html.en, 0x002A7500) = 0 11140: Incurred fault #6, FLTBOUNDS %pc = 0xFF05990C 11140:siginfo: SIGSEGV SEGV_MAPERR addr=0x005C 11140: Received signal #11, SIGSEGV [default] 11140:siginfo: SIGSEGV SEGV_MAPERR addr=0x005C 11140: *** process killed *** And this is the stack when the crash happens: core file = /opt/OCTOapache-1.3.22/core -- program ``httpd'' on platform SUNW,Ultra-250 SIGSEGV: Segmentation Fault $C yy_get_next_buffer(0x1aafd8,0x1a2818,0x2,0x0,0x0,0x0) + 21c [savfp=0xffbef830,savpc=0x7555c] ap_clear_pool(0x1a2818,0x1a6818,0x0,0x0,0x0,0x0) + 4c [savfp=0xffbef8a0,savpc=0x755ec] ap_destroy_pool(0x1a2818,0x19e818,0x0,0xff238018,0xffbeda11,0x0) + 14 [savfp=0xffbef910,savpc=0x75544] ap_clear_pool(0x19e818,0xff23fa9c,0x0,0xa,0x0,0xffbed9d0) + 34 [savfp=0xffbef980,savpc=0x755ec] ap_destroy_pool(0x19e818,0x19a9a0,0xd,0x1a2840,0x0,0x16ca98) + 14 [savfp=0xffbef9f0,savpc=0x8b0b8] clean_parent_exit(0x0,0x13d2,0xd,0x1a2840,0x16ca98,0x16c800) + 14 [savfp=0xffbefa60,savpc=0x8f044] standalone_main(0x1,0xffbefbfc,0x0,0x0,0xff23b03c,0x16cb58) + 764 [savfp=0xffbefae8,savpc=0x8f824] main(0x1,0xffbefbfc,0xffbefc04,0x19b5f4,0x0,0x0) + 51c [savfp=0xffbefb98,savpc=0x2a320] When I comment out the LoadModule and the AddModule line, the HEAD request is OK: telnet localhost 8088 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. HEAD / HTTP/1.0 HTTP/1.1 200 OK Date: Wed, 24 Oct 2001 17:14:57 GMT Server: Apache/1.3.22 (Unix) mod_perl/1.26 Last-Modified: Fri, 04 May 2001 00:00:38 GMT ETag: 398ee-5b0-3af1f126 Accept-Ranges: bytes Content-Length: 1456 Connection: close Content-Type: text/html Content-Language: en Connection closed by foreign host. I had PHP 4.0.4pl1 running OK with the same apache. This happened after I compiled 4.0.6 with the same configuration and installed it over 4.0.4pl1. Edit this bug report at http://bugs.php.net/?id=13816edit=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]
[PHP-DEV] ¤ÑµMĪîP¦b¼ê´ò
±z¦pªGÁA¸ÑĪîPªº¾ú¥v¡A¨º¨Ç¼Æ¤]¼Æ¤£²Mªº¶Ç©_¬G¨Æ¡A
±q¥j®J¤ÎÆv¦Z¥ÎĪîP¨Ó¾iÃC¬ü¥Õ¡B¼í¾v¡A
¨ì¨È¾ú¤s¤j¤j«Ò¥²¶·¥ý¦û¾Ú¤ÑµMĪîP¸ê·½¡A
¨ÏÂåªv¶Ë§Lªº°ÝÃD±o¨ì¸Ñ¨M«á¡A¤~´±©ñ¤â¥X©ºµ¥µ¥¡A
§Ú´N¤£¦b³o¨àÂØz¤F¡C
¼ê´ò¿¤¦]¦a²zÀô¹Ò¯S®í¡A¤SµL¤u¼t¿äÆn¡A
¬O¶ôµL¦Ã¬V¤S¯Â¤ÑµM¤§¼Ö¤g¡A©Ò¥H³¥¥Í¤ÑµM´Óª«¯S¦h¡A
¨Ò¡GĪîP¡N»¯ø¯ó¡]¤S¥s·¯ø¯ó¡^¡N¥P¤H´xµ¥¡C
§Ú̦A¦¸ÅTÀ³¬F©²¹A·~¬ì§Þ¡A
¯S®âºØ¥þ¥@¬É²Ä¤@¦nĪîP¡©¦N©Ô¯Á¡ª«~ºØ¡A
¥Ñ¦æ¬F°|¹A©e·|»²¾É¡A°ê¥ß¹Å¸q¤j¾Ç§Þ³N¦¨¥\¬ãµo¡A
±NĪîPªº¦UºØ¯«©_¥\®Ä¶}µo¥X¨Ó¡A»s¦¨²£«~¡A
µ´¹ï«~½è«OÃÒ¡A«H¥Î¥i¾a¡A¤£³×¬°°ê¤H¤@¤jºÖµ¡C
ĪîP¹ï¤HÅ骺¥\®Ä¡A¦¤w¨ü¨ì°ê»ÚªºªÖ©w¡A
¤£¤Ö¼Ú¬ü¥ý¶i°ê®a¤@ª½¦b¦³³W¼Òªº®â°öĪîP¡A
¦ÓÁÚ¦V¦Û°Ê¤Æ¡B¬ì¾Ç¤Æªº¹Lµ{¡C
¥h°£§t¦³ÄªîP¤j¶À¥Ìªºªí¥Ö¡A¥uÂ^¨úĪîP³z©úÂ׫pªº¦×¥Ä»s¦¨¦UºØ°·±d¶¼®Æ¡A
µL½×¹ï¸É¥RÀç¾i©M¬Y¨Ç¯e¯fªºªvÀø¡A³£¦³¥¦¹ïÂå¾Ç»{©wªº®ÄªG¡C
ĪîP¦³¤Uz¦n³B¡G
ĪîP§t¦³¦åºÞµÎ½w¿E¤À¸Ñ¦è¨C¡A¥¦¥i¥H§½³¡®ø¿æ¤îµh¡A
¦]¬°¥¦¬O»Ã¯À¤ô¸ÑªºÃö«Y¡A¥i¥H§â¦åºÞµÎ½w¿E¤ô¸Ñ±¼¡C
ĪîP§t¦³¨Å»ÄÁâ¡A¥¦¥i¥H¤îÄo¡A¤]¥i¥H¨¾¤î²Õ´§Î¦¨¡A
©Ò¥H¡A¥~¥Î¤W¡AĪîP¥i¥H®ø¸~¤îµh¡B¤îÄo¡F
¤S¦]¬°§t¦³¦åºÞµÎ½w¿E¯»¸Ñ¦è¨C¡A¥i¥H«P¶i¤Àªc¦åºÞ¦¬ÁY¯À¡A
©Ò¥H¡A¥i¥H¡¦X¶Ë¤f¡C
¬ü®e¤è±¡G
(1)ĪîP¦bÂå¾Ç¤W´N¦³¤ÑµMªº¬ü¥Õ¥\§ð¡A¦³Á{§Éªº¹êÅ礧¨Æ¹ê¡A
¬~±¨Å»P»¨m¬ü¥Õªº¥\§ð³£«D±`ªº¦n
(2) §t¦³³J¥Õ½è¡BºÒ¤ô¤Æ¦Xª«¡A¥i¥HÀç¾i¥Ö½§¡F
(3) §t¦³ÂH°ª¤À¤l¦hÁÞÅé¡A¥i¥H´þ¼í¥Ö½§¤G¤Q´X¤p®É¡F
(4) §t¦³ºû¥L©RB12¡A¹ï©óµo¿N¡BÀYµh¡Bµê®z·P¡B¯h·P¡B
«K¯¦¡B³y¦å¥\¯à¡B³ïÄVµh¦³À°§U¡F
(5)§t¦³¦¬ÀĦ¨¥÷¡AÀ°§U¥Ö½§²ÓM²£¥Í¦¬ÀĮĪG¡A¨¾¤î½K¯¾²£¥Í¡F
(6)§t¦³«e¦C¸¢¯ÀE2§í¨î¾¯¡A©Ò¥H¹ï¨Å馳®øª¢§@¥Î¡F
(7)§t¦³°ª¤À¤l¦hÁÞÅé¡A¨ã¦³§K¬Ì¥\¯à¼W±j¡B§í¨î¿æ½F¥Íªøªº®ÄªG¡C
¼ê´ò¿¤¹A·|²×©ó¨Ï°ê¤H¾Ö¦³«~½è¯SÀu¡B»ù®æ¹ê¦bªº¦Û²£¦Û»sĪîP¤F¡A
Åwªï°ÑÆ[¡B½u¤WqÁÊ¡G http://www.phfa.com.tw
¬¢¸ß±M½uTel¡G(06)6831362 ¤â¾÷¡G0932718630 ³sµ¸¤H¡GJ¤p©j
--
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]
[PHP-DEV] Bug #13094 Updated: Upload very slow
ID: 13094
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Old Status: Assigned
Status: Closed
Bug Type: Performance problem
Operating System: Windows 2000
PHP Version: 4.0.6
Assigned To: sniper
New Comment:
Fixed in CVS by Jani, will be fixed in 4.2.0
Previous Comments:
[2001-09-02 16:52:23] [EMAIL PROTECTED]
Work in progress...
[2001-09-02 11:57:36] [EMAIL PROTECTED]
This has nothing to do with 2291.
The problem probably is that PHP takes all HTTP-post data into it's memory, and only
after the complete header (WITH all files) are in-memory, php_mime_split is called to
get the files out of the request and save them to disk.
So if you need to recieve file-uploads of 100MB or something, PHP needs 100MB of
RAM... otherwise it will swap and thus be terribly slow (especially on Windows)
A real solution would be to rewrite php_mime_split to run on-the-fly... which at first
glance isn't terribly hard.
[2001-09-02 11:17:11] [EMAIL PROTECTED]
Seems duplicate of 2291, but that one should be fixed in 4.0.6
[2001-09-02 07:34:53] [EMAIL PROTECTED]
?php
if(is_uploaded_file($userfile))
{
$FileNameAdd = $FileName;
//Prefix for filename using uniqid();
$FileNameAddDB = $DBFileName; //Including prefix
used for database
$filename = $HTTP_POST_FILES['userfile']['name']; //Filename as selected
by user
$FileExt = substr(strrchr($filename, .), 1);
if(array_search($FileExt, $Extensions) == FALSE)
{
?
font class=warningNot allowed to upload this file./font
?php
exit();
}
$DBFileSize = $HTTP_POST_FILES['userfile']['size'];
$DBFileName = $FileNameAddDB.$filename;
move_uploaded_file($userfile, $Mapping . $FileNameAdd.$filename);
?
Didn't compile anything just use the compiled version as download from website.
When I upload a file bigger than 10 MB, it takes a very long time (if it uploads) I
adjusted all the needed variables in php.ini.
I'm using it for files (150MB) over a Lan network.
I've tried a ASP uploader and it does the same file in less then three minutes. PHP
was working for 30 minutes and still wasn't done.
I think this is a bug in the code.
Marcel van Leeuwen
Netherlands
Edit this bug report at http://bugs.php.net/?id=13094edit=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]
[PHP-DEV] Bug #8377 Updated: File uploads with POST methods takes full Server processing capacity and memory
ID: 8377 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Assigned Status: Closed Bug Type: Feature/Change Request Operating System: Windows NT4/2000 PHP Version: 4.0.4 Old Assigned To: sniper Assigned To: New Comment: This should be fixed in CVS now. You can try the latest development build from http://www.php4win.com/ but make sure it's dated after 27th of October 2001. Also, there are some minor leaks still in the new code. If you encounter such leaks, please send the shortest possible code + html with which you can reproduce the leak to [EMAIL PROTECTED] (or me) so we can get rid of these leaks. The fix will be in PHP 4.2.0. --Jani Previous Comments: [2001-09-17 13:14:58] [EMAIL PROTECTED] I've been working on this issue. The fix won't be in 4.0.7/4.1 but hopefully in the next release after those. --Jani [2001-05-09 11:10:59] [EMAIL PROTECTED] Marked as to be fixed before 4.0.6 [2001-05-01 22:09:20] [EMAIL PROTECTED] Just to note that this is still a problem.. I tried with 1Gb file and my system almost crashed. (On Linux) --Jani [2000-12-22 16:34:12] [EMAIL PROTECTED] This is a known inefficiency. Jim Winstead is looking addressing this using libapreq which is smarter about handling large file uploads. (Moving to feature request) [2000-12-22 10:16:58] [EMAIL PROTECTED] When doing a file upload on a big file (say 22MB), PHP takes up progressingly more CPU capacity for the whole duration of the upload. The server doesn't crashes but it is so slow that other people can't reach my server, when i'm uploading a big file. I now use a ASP-component on the server-side which handles the uploading and this component doesn't slow my server down when uploading a big file. Can PHP handle big file uploads in the future? This is the HTML that uploads the file: input type=hidden name='MAX_FILE_SIZE' value='2500' input type='file' size='50' name='frm_file_name' class='input' value=''/input Edit this bug report at http://bugs.php.net/?id=8377edit=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]
[PHP-DEV] Bug #13435 Updated: fileupload and filedownload
ID: 13435 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Assigned Status: Closed Bug Type: HTTP related Operating System: windows 2000 pro PHP Version: 4.0.6 Old Assigned To: sniper Assigned To: New Comment: This should be fixed in CVS now. You can try the latest development build from http://www.php4win.com/ but make sure it's dated after 27th of October 2001. Also, there are some minor leaks still in the new code. If you encounter such leaks, please send the shortest possible code + html with which you can reproduce the leak to [EMAIL PROTECTED] (or me) so we can get rid of these leaks. The fix will be in PHP 4.2.0. --Jani Previous Comments: [2001-09-25 17:11:48] [EMAIL PROTECTED] I'm working on this.. [2001-09-25 13:43:00] [EMAIL PROTECTED] Ahhm forgot the environment: Win2kPro, Apache (latest),MySQL,RAID-System for IDE, 128MB of ram and about 40 GB free harddisk. The php.ini was configured for 100mb posts and 100mb files, using 64 MB of memory for each script. [2001-09-25 13:37:15] [EMAIL PROTECTED] While uploading thru intranet, the PHP-process uses 99% of CPU, lots of memory (up to twice as much as the file itself) and takes 3/4 hour for 40 MB. While sending this file back using fopen/passthru, it takes a lot time until the browsers download-dialog opens. Then the transfer itself ist very quick ! That's why I guess it is not a http-problem, but a problem in handling files or handling memory ! Another hint on this is, that large files seem to get back corrupt, as testing a large and downloaded file resulted in some crc-errors. On small files all works fine. This one might be relatet to the bug 10800 (or 10080 %o), so have a look at that. Edit this bug report at http://bugs.php.net/?id=13435edit=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]
Re: [PHP-DEV] Bug #13094 Updated: Upload very slow
Please leave alone these. I was going to close them myself as I want to add some information to them too.. I'm sorry, you committed the fix yesterday early, and I thought you might have forgotten them. (but should've know better) I should've mailed you instead, I got a 'then this bug is fixed or not?' mail from the submitter. --Jeroen -- 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]
[PHP-DEV] Bug #13859: Inconsistent display of logical results
From: [EMAIL PROTECTED] Operating system: Windows95 PHP version: 4.0.6 PHP Bug Type: Performance problem Bug description: Inconsistent display of logical results ?php $n1=10; $n2=8; echo '$n1$n2 is '.($n1$n2).br; echo '$n1=$n2 is '.($n1=$n2).br; echo '$n1$n2 is '.($n1$n2).br; echo '$n1=$n2 is '.($n1=$n2).br; echo '$n1==$n2 is '.($n1==$n2).br; echo '$n1!=$n2 is '.($n1!=$n2).br; echo '$n1$n2 is '.($n1$n2).br; echo '$n1===$n2 is '.($n1===$n2).br; echo '$n1!==$n2 is '.($n1!==$n2).br; echo br; $bool=($n1==$n2 || $n1===$n2); echo '$bool=($n1==$n2 || $n1===$n2);'.br; echo '$bool is '.$bool; ? --- This code is a simple run-through of the logical operators. The problem is that 0 is never displayed normally, but if you use boolean logic, then it is possible for 0 to be displayed. I prefer the 0 being displayed. -- Edit bug report at: http://bugs.php.net/?id=13859edit=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]
[PHP-DEV] Bug #13094 Updated: Upload very slow
ID: 13094
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Performance problem
Operating System: Windows 2000
PHP Version: 4.0.6
Assigned To: sniper
New Comment:
This should be fixed in CVS now. You can try the latest
development build from http://www.php4win.com/ but make
sure it's dated after 27th of October 2001.
Also, there are some minor leaks still in the new code.
If you encounter such leaks, please send the shortest
possible code + html with which you can reproduce the leak
to [EMAIL PROTECTED] (or me) so we can get rid of these
leaks.
The fix will be in PHP 4.2.0.
--Jani
Previous Comments:
[2001-10-28 12:10:12] [EMAIL PROTECTED]
Fixed in CVS by Jani, will be fixed in 4.2.0
[2001-09-02 16:52:23] [EMAIL PROTECTED]
Work in progress...
[2001-09-02 11:57:36] [EMAIL PROTECTED]
This has nothing to do with 2291.
The problem probably is that PHP takes all HTTP-post data into it's memory, and only
after the complete header (WITH all files) are in-memory, php_mime_split is called to
get the files out of the request and save them to disk.
So if you need to recieve file-uploads of 100MB or something, PHP needs 100MB of
RAM... otherwise it will swap and thus be terribly slow (especially on Windows)
A real solution would be to rewrite php_mime_split to run on-the-fly... which at first
glance isn't terribly hard.
[2001-09-02 11:17:11] [EMAIL PROTECTED]
Seems duplicate of 2291, but that one should be fixed in 4.0.6
[2001-09-02 07:34:53] [EMAIL PROTECTED]
?php
if(is_uploaded_file($userfile))
{
$FileNameAdd = $FileName;
//Prefix for filename using uniqid();
$FileNameAddDB = $DBFileName; //Including prefix
used for database
$filename = $HTTP_POST_FILES['userfile']['name']; //Filename as selected
by user
$FileExt = substr(strrchr($filename, .), 1);
if(array_search($FileExt, $Extensions) == FALSE)
{
?
font class=warningNot allowed to upload this file./font
?php
exit();
}
$DBFileSize = $HTTP_POST_FILES['userfile']['size'];
$DBFileName = $FileNameAddDB.$filename;
move_uploaded_file($userfile, $Mapping . $FileNameAdd.$filename);
?
Didn't compile anything just use the compiled version as download from website.
When I upload a file bigger than 10 MB, it takes a very long time (if it uploads) I
adjusted all the needed variables in php.ini.
I'm using it for files (150MB) over a Lan network.
I've tried a ASP uploader and it does the same file in less then three minutes. PHP
was working for 30 minutes and still wasn't done.
I think this is a bug in the code.
Marcel van Leeuwen
Netherlands
Edit this bug report at http://bugs.php.net/?id=13094edit=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]
[PHP-DEV] Bug #13859 Updated: Change (string)false from to 0
ID: 13859 Updated by: jeroen Reported By: [EMAIL PROTECTED] Old Summary: Inconsistent display of logical results Old Status: Open Status: Closed Old Bug Type: Performance problem Bug Type: Feature/Change Request Operating System: Windows95 PHP Version: 4.0.6 New Comment: Reclassified and updated summary. But it's not going to happen, therefore closed. There are numerous reasons for todays behaviour. use var_dump anyway if you are interested in the value of an expression, and/or if() or something alike if you want to use the truth value of a variable. See also: http://www.php.net/types Previous Comments: [2001-10-28 12:22:40] [EMAIL PROTECTED] ?php $n1=10; $n2=8; echo '$n1$n2 is '.($n1$n2).br; echo '$n1=$n2 is '.($n1=$n2).br; echo '$n1$n2 is '.($n1$n2).br; echo '$n1=$n2 is '.($n1=$n2).br; echo '$n1==$n2 is '.($n1==$n2).br; echo '$n1!=$n2 is '.($n1!=$n2).br; echo '$n1$n2 is '.($n1$n2).br; echo '$n1===$n2 is '.($n1===$n2).br; echo '$n1!==$n2 is '.($n1!==$n2).br; echo br; $bool=($n1==$n2 || $n1===$n2); echo '$bool=($n1==$n2 || $n1===$n2);'.br; echo '$bool is '.$bool; ? --- This code is a simple run-through of the logical operators. The problem is that 0 is never displayed normally, but if you use boolean logic, then it is possible for 0 to be displayed. I prefer the 0 being displayed. Edit this bug report at http://bugs.php.net/?id=13859edit=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]
[PHP-DEV] Bug #13852 Updated: zlib file reading functions not working in Apache Module version
ID: 13852
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Zlib Related
Operating System: Windows 2000
PHP Version: 4.0.4pl1
New Comment:
even with error_reporting(E_ALL) i don't get any error messages from the script. i
already had tried this.
i have both the cgi and win-apache server module version of php installed parallely.
.php files are mapped to the php module and .phpc to cgi. that way it is very easy to
compare the output of an identical script by just renaming it.
while as cgi the script outputs the textfile as expected, the module doesn't give me
anything.
i only have one php.ini on my system, which resides in winnt\system32\php.ini. it is
used by the cgi and module.
?php
error_reporting(E_ALL);
$log = gzfile('test.gz');
foreach ($log as $l) echo $lbr;
?
phil.
Previous Comments:
[2001-10-28 11:37:48] [EMAIL PROTECTED]
Probably not a bug (cgi does work, so very unlikely to be a bug in PHP or zlib). Ask
support questions on http://www.php.net/support.php , or reopen if I'm wrong.
Try this:
Please check the location of your php.ini, that you're editing the right one. (check
wether modifications show up in a phpinfo() page).
And check your error reporting level, set it to E_ALL (error_reporting(E_ALL); before
anything). My guess is it's giving undefined function errors.
[2001-10-27 16:58:01] [EMAIL PROTECTED]
most of the zlib file reading functions, like gzfile,gzread,gzpassthru,gzgetc do not
work in the Apache Module version of php.
the function returns no value - without outputting any error or warning; sometimes the
webserver crashes.
when i switched php to run as cgi everything works as expected.
don't know if this has been fixed, couldn't find an entry in the bugfinder.
phil.
running extensions:
extension=php_zlib.dll
extension=php_sablot.dll
extension=php_gd.dll
extension=php_pdf.dll
demo script (test.gz would be ascii text):
$log = gzfile('test.gz');
foreach ($log as $l) echo $lbr;
Edit this bug report at http://bugs.php.net/?id=13852edit=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]
[PHP-DEV] Re: Bug #13816 Updated: Accessing a static HTML page crashes Apache
On Sunday, 2001-10-28 at 16:50:21 -, Bug Database wrote: ID: 13816 Updated by: sniper Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Reproducible crash Operating System: Solaris 8 SPARC PHP Version: 4.0.6 New Comment: Try removing mod_perl and see if it works then. --Jani This is a major hassle. Running without mod_perl is not an option (as is running without PHP). But this means that I have to redo the Apache config from the Apache side. I normally use mod_perl's Makefile.PL to do the work for me. You have no clue what is wrong, don't you? I will see if I can find the time to do the Apache config from scratch. Lupe Christoph -- | [EMAIL PROTECTED] |http://free.prohosting.com/~lupe | | I have challenged the entire ISO-9000 quality assurance team to a | | Bat-Leth contest on the holodeck. They will not concern us again. | | http://public.logica.com/~stepneys/joke/klingon.htm| -- 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]
Re: [PHP-DEV] Bug #13846 Updated: Patch: Use [ ] as shortcut forarray()
On Sun, 28 Oct 2001 17:40:40 +0200 (EET), Jani Taskinen wrote:
On Sun, 28 Oct 2001, Zakaria wrote:
For example:
Perl: $list = (1, 2 ,3, 'four', 'five', (6.1, 6.2, 6.3));
Python: list = [1, 2, 3, 'four', 'five', [6.1, 6.2, 6.3]]
Ruby: list = [1, 2, 3, 'four', 'five', [6.1, 6.2, 6.3]]
Tcl: set list {1 2 3 four five {6.1 6.2 6.3}}
PHP: $list = array(1, 2, 3, 'four', 'five', array(6.1, 6.2, 6.3));
Which clearly shows that PHP is readable and all the other languages are
not. -10 from me to this feature.
I could have never explained that better. Please _don't_ introduce such
a syntax in PHP.
- Martin
--
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]
Re: [PHP-DEV] Bug #13846 Updated: Patch: Use [ ] as shortcut forarray()
On Sun, 28 Oct 2001, Zakaria wrote:
For example:
Perl: $list = (1, 2 ,3, 'four', 'five', (6.1, 6.2, 6.3));
Python: list = [1, 2, 3, 'four', 'five', [6.1, 6.2, 6.3]]
Ruby: list = [1, 2, 3, 'four', 'five', [6.1, 6.2, 6.3]]
Tcl: set list {1 2 3 four five {6.1 6.2 6.3}}
PHP: $list = array(1, 2, 3, 'four', 'five', array(6.1, 6.2, 6.3));
Which clearly shows that PHP is readable and all the other languages are
not. -10 from me to this feature.
And these example are still a bit readable, but what about:
$arr1 = [];
$arr2[10] = [2];
$foo = bla('arg1', [2, 3, 4]);
and such cases...
So indeed a bad idea.
--Jeroen
--
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]
Re: [PHP-DEV] Bug #13846 Updated: Patch: Use [ ] as shortcut forarray()
Still readable without problems to me ;) - Markus -- 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]
Re: [PHP-DEV] Bug #13846 Updated: Patch: Use [ ] as shortcut forarray()
Still readable without problems to me ;) The syntax is ugly -10 from me :) - James -- 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]
[PHP-DEV] [PATCH] for safe_mode
Hi!
I've produced a simple patch for PHP 4.0.6 which enables administrator to
allow scripts access to include dir eg. for some common php scripts, during
safe_mode of course.
Anyway it may produce a bug [dunno why :(] that causes open_basedir to be
turned on automagically when include_path is set.
--
email: [[EMAIL PROTECTED]] gsm: +48 606 787423
echo Ecl.Pl Al. NMP 31 Czstochowa http://www.ecl.pl/
//Ja zaczn programowa, a ty dowiedz si, czego chc
diff -ur main.orig/main.c main/main.c
--- main.orig/main.cTue May 8 22:11:46 2001
+++ main/main.c Sun Oct 28 20:21:04 2001
@@ -221,6 +221,7 @@
PHP_INI_ENTRY(max_execution_time, 30,
PHP_INI_ALL,OnUpdateTimeout)
STD_PHP_INI_ENTRY(open_basedir, NULL,
PHP_INI_SYSTEM, OnUpdateStringUnempty, open_basedir,
php_core_globals, core_globals)
STD_PHP_INI_ENTRY(safe_mode_exec_dir, 1,
PHP_INI_SYSTEM, OnUpdateString, safe_mode_exec_dir,
php_core_globals, core_globals)
+ STD_PHP_INI_ENTRY(safe_mode_include_dir, 1,
+PHP_INI_SYSTEM, OnUpdateString, safe_mode_include_dir,
+ php_core_globals, core_globals)
STD_PHP_INI_ENTRY(upload_max_filesize,2M, PHP_INI_ALL,
OnUpdateInt,upload_max_filesize,php_core_globals,
core_globals)
STD_PHP_INI_ENTRY(file_uploads, 1,
PHP_INI_ALL,OnUpdateBool, file_uploads,
php_core_globals, core_globals)
STD_PHP_INI_ENTRY(post_max_size, 8M,
PHP_INI_SYSTEM, OnUpdateInt,post_max_size,
sapi_globals_struct,sapi_globals)
diff -ur main.orig/php_globals.h main/php_globals.h
--- main.orig/php_globals.h Wed Apr 4 22:46:26 2001
+++ main/php_globals.h Sun Oct 28 20:20:35 2001
@@ -74,6 +74,7 @@
char *output_handler;
char *safe_mode_exec_dir;
+ char *safe_mode_include_dir;
long memory_limit;
diff -ur main.orig/safe_mode.c main/safe_mode.c
--- main.orig/safe_mode.c Mon Apr 30 14:43:40 2001
+++ main/safe_mode.cSun Oct 28 20:23:27 2001
@@ -69,6 +69,16 @@
return 1;
}
+ /*
+ * Added by [EMAIL PROTECTED] - check if the file is in special
+ * directory where all system includes go [like autoprepend directives]
+ */
+
+if ( !strncasecmp(filename, PG(safe_mode_include_dir),
+strlen( PG(safe_mode_include_dir) )) ) {
+return 1;
+}
+
if (mode != CHECKUID_ALLOW_ONLY_DIR) {
ret = VCWD_STAT(filename, sb);
if (ret 0) {
--
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]
[PHP-DEV] Bug #12651 Updated: Constant 'Broken pipe' errors
ID: 12651 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Performance problem Operating System: Linux 2.2 PHP Version: 4.0.6 New Comment: The warning messages are not a bug and are due to Apache LogLevel being changed to 'info'. The 'hung' connections seem to have eased although not disappeared. Am viewing it as a 'voodoo' (i.e. mystery, hard-to-reproduce) problem. If someone else has noticed something similar, consider reopening the bug (or creating a new one with specifically that report). Previous Comments: [2001-08-08 08:38:09] [EMAIL PROTECTED] Since upgrading from 4.0.5 to 4.0.6, I see constant errors in the logs for all my virtual hosts: (32)Broken pipe: client stopped connection before send mmap completed Alongside this, I have noticed that frequently when I am using functions on my sites (particularly submitting forms via POST), the connection just times out without a response (although the PHP script HAS executed since the functions it was supposed to perform were done). I'm not aware of any other configuration changes that might have caused this. I can't find anything on the lists/bugs about it. Edit this bug report at http://bugs.php.net/?id=12651edit=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]
[PHP-DEV] Bug #13860: Bzip2 bzdecompress function is wery slow...
From: [EMAIL PROTECTED] Operating system: Windows 98 SE PHP version: 4.0.6 PHP Bug Type: Bzip2 Related Bug description: Bzip2 bzdecompress function is wery slow... I made a little decompresser script: ?php $efilename = d:/pic.bz2; //A compressed jpg image ( original size: 388kbyte, packed size: 388kbyte) $ufilename2 = d:/pic.jpg; $fp = fopen($efilename, rb); $ecd_cont = fread($fp, filesize($efilename)); //read the compressed data from file fclose($fp); $fp = fopen($ufilename2,wb); $ecd_cont = bzdecompress($ecd_cont,1); //decompress the readed compressed data fwrite($fp, $ecd_cont); //write the decompressed data into file fclose($fp); echo img src=\file://d:\\pic.jpg\; ? Ok, this is work... But it is WERY WERY slow!!! It's take 60sec to display the decompressed image, why?? I made the decompression befor with an other method: ?php $efilename = d:/pic.bz2; $ufilename2 = d:/pic.jpg; $bz = bzopen($efilename, rb); $ecd_cont = bzread($bz, 40); // See below bzlose($bz); $fp = fopen($ufilename2,wb); fwrite($fp, $ecd_cont); fclose($fp); echo img src=\file://d:\\pic.jpg\; ? Ok this is working (And this is fast! The decompressed picture appears immediately), but there is a little problem: In the PHP manual I read this about the bzread() function: If the optional parameter length is not specified, bzread() will read 1024 (uncompressed) bytes at a time. Ok, so it will read 1024 uncompressed bytes from my compressed file, if I not give the lenght parameter (as I did in the example). But there is a problem: if I want to be precise then I must give the lenght of the original file, but how??? I only have the compressed file, which is not equal with the original (ok, in my example it is, but only because the original jpg-compressed file), so I cant use the filesize() function, because it gave only the compressed filesize, neither the strlen() because I havnt got a string yet :) And I think you agree with me if I dont want to write 400Mbyte to parameter... this is not a correct solution. I think the correct solution if the bzread() function is read the entire file if I dont give the lenght parameter. -- Edit bug report at: http://bugs.php.net/?id=13860edit=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]
[PHP-DEV] Bug #13860 Updated: Bzip2 bzdecompress function is wery slow...
ID: 13860 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Bzip2 Related Operating System: Windows 98 SE PHP Version: 4.0.6 New Comment: bzdecompress($ecd_cont,1); I'm used it without the 1 parameter, i'm just tryed uot what happen if i use it... Previous Comments: [2001-10-28 15:34:18] [EMAIL PROTECTED] I made a little decompresser script: ?php $efilename = d:/pic.bz2; //A compressed jpg image ( original size: 388kbyte, packed size: 388kbyte) $ufilename2 = d:/pic.jpg; $fp = fopen($efilename, rb); $ecd_cont = fread($fp, filesize($efilename)); //read the compressed data from file fclose($fp); $fp = fopen($ufilename2,wb); $ecd_cont = bzdecompress($ecd_cont,1); //decompress the readed compressed data fwrite($fp, $ecd_cont); //write the decompressed data into file fclose($fp); echo img src=\file://d:\\pic.jpg\; ? Ok, this is work... But it is WERY WERY slow!!! It's take 60sec to display the decompressed image, why?? I made the decompression befor with an other method: ?php $efilename = d:/pic.bz2; $ufilename2 = d:/pic.jpg; $bz = bzopen($efilename, rb); $ecd_cont = bzread($bz, 40); // See below bzlose($bz); $fp = fopen($ufilename2,wb); fwrite($fp, $ecd_cont); fclose($fp); echo img src=\file://d:\\pic.jpg\; ? Ok this is working (And this is fast! The decompressed picture appears immediately), but there is a little problem: In the PHP manual I read this about the bzread() function: If the optional parameter length is not specified, bzread() will read 1024 (uncompressed) bytes at a time. Ok, so it will read 1024 uncompressed bytes from my compressed file, if I not give the lenght parameter (as I did in the example). But there is a problem: if I want to be precise then I must give the lenght of the original file, but how??? I only have the compressed file, which is not equal with the original (ok, in my example it is, but only because the original jpg-compressed file), so I cant use the filesize() function, because it gave only the compressed filesize, neither the strlen() because I havnt got a string yet :) And I think you agree with me if I dont want to write 400Mbyte to parameter... this is not a correct solution. I think the correct solution if the bzread() function is read the entire file if I dont give the lenght parameter. Edit this bug report at http://bugs.php.net/?id=13860edit=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]
[PHP-DEV] Bug #13860 Updated: Bzip2 bzdecompress function is wery slow...
ID: 13860 Updated by: jeroen Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Old Bug Type: Bzip2 Related Bug Type: Performance problem Operating System: Windows 98 SE PHP Version: 4.0.6 New Comment: Please don't but multiple issues in one report, and keep your report short. (bugs do's and don'ts) I'm transforming this report into performance question of bzip, open a new feature/change request on the second parameter. you use bzdecompress(..., TRUE), i.e. you tell it to be two times slower... Then you shouldn't complain about performance, bzip is very strong compression at the cost of high memory and cpu usage. And you read the whole file in memory, decompress it, write it back to disk... that's very inefficient. So this is not a bug in PHP, but a problem with your script. Ask http://www.php.net/support.php for support questions on how to do things efficiently. Compressing JPG's is a quite useless practice by the way... jpg is already compressed. Previous Comments: [2001-10-28 15:57:28] [EMAIL PROTECTED] bzdecompress($ecd_cont,1); I'm used it without the 1 parameter, i'm just tryed uot what happen if i use it... [2001-10-28 15:34:18] [EMAIL PROTECTED] I made a little decompresser script: ?php $efilename = d:/pic.bz2; //A compressed jpg image ( original size: 388kbyte, packed size: 388kbyte) $ufilename2 = d:/pic.jpg; $fp = fopen($efilename, rb); $ecd_cont = fread($fp, filesize($efilename)); //read the compressed data from file fclose($fp); $fp = fopen($ufilename2,wb); $ecd_cont = bzdecompress($ecd_cont,1); //decompress the readed compressed data fwrite($fp, $ecd_cont); //write the decompressed data into file fclose($fp); echo img src=\file://d:\\pic.jpg\; ? Ok, this is work... But it is WERY WERY slow!!! It's take 60sec to display the decompressed image, why?? I made the decompression befor with an other method: ?php $efilename = d:/pic.bz2; $ufilename2 = d:/pic.jpg; $bz = bzopen($efilename, rb); $ecd_cont = bzread($bz, 40); // See below bzlose($bz); $fp = fopen($ufilename2,wb); fwrite($fp, $ecd_cont); fclose($fp); echo img src=\file://d:\\pic.jpg\; ? Ok this is working (And this is fast! The decompressed picture appears immediately), but there is a little problem: In the PHP manual I read this about the bzread() function: If the optional parameter length is not specified, bzread() will read 1024 (uncompressed) bytes at a time. Ok, so it will read 1024 uncompressed bytes from my compressed file, if I not give the lenght parameter (as I did in the example). But there is a problem: if I want to be precise then I must give the lenght of the original file, but how??? I only have the compressed file, which is not equal with the original (ok, in my example it is, but only because the original jpg-compressed file), so I cant use the filesize() function, because it gave only the compressed filesize, neither the strlen() because I havnt got a string yet :) And I think you agree with me if I dont want to write 400Mbyte to parameter... this is not a correct solution. I think the correct solution if the bzread() function is read the entire file if I dont give the lenght parameter. Edit this bug report at http://bugs.php.net/?id=13860edit=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]
[PHP-DEV] Bug #11116 Updated: File upload sometimes work, sometimes fails
ID: 6
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: HTTP related
Operating System: win NT 4
PHP Version: 4.0.5
New Comment:
You're setting the maximum filesize to be 4096 bytes.
That might be the reason for the uploads to fail?
Not many normal files are that small.
--Jani
Previous Comments:
[2001-06-01 04:33:14] [EMAIL PROTECTED]
It seems that binary files always fail and others sometimes fail.
I thought it could be wise to add the submit form I use.
form ENCTYPE=multipart/form-data action=? $PHP_SELF ? method=post
input type=hidden name=typePub value=file
input type=hidden name=MAX_FILE_SIZE value=4096
input type=file name=leFichier
...
/form
[2001-05-31 22:53:09] [EMAIL PROTECTED]
Is there any pattern of files you can't upload? like,
are they always binary files that fail?
--Jani
[2001-05-29 03:26:55] [EMAIL PROTECTED]
Tried php 4.0.5 = same problem.
I can *sometimes* upload files, *sometimes* i can't!?
[2001-05-25 11:37:36] [EMAIL PROTECTED]
I followed the method in the online manual to set up a small file upload.
It works well with some files and fails with some others!
if (is_uploaded_file($uploadedFile))
{
echo UPLOAD OKbr;
...
}
else
{
echo upload KO;
}
I try to rename the files.
I tried with files in my c:\ root dir.
(local system: winMe)
Some will get uploaded some wont!?
Tried long/short names
Files are about 1-10k large for testing purpose
Are there any upload rules ?
Thanks in advance
Edit this bug report at http://bugs.php.net/?id=6edit=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]
[PHP-DEV] Bug #9460 Updated: File upload problem when the form control name is an array element
ID: 9460 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: HTTP related Operating System: Suse (2.2.16 kernel) PHP Version: 4.0.4pl1 New Comment: Works fine with latest CVS. --Jani Previous Comments: [2001-02-26 08:01:57] [EMAIL PROTECTED] Precis: I was trying to submit a form divided into sections, each section having a two text fields and a file upload. The form was structured as an array called $section, each element an array containing firstname, surname and image. The image details I expected to turn up in $HTTP_POST_FILES as $HTTP_POST_FILES[section][0][name] etc. That behaved as expected. The other form elements I expected to turn up as $HTTP_POST_VARS[section][0][firstname] etc. However what I ended up with was $HTTP_POST_VARS[section][0] being set to the filesize of the uploaded file, overwriting all other elements in that section. // ---start upload.php-- ?php print pre\nVars:\n; print_r($HTTP_POST_VARS); print \nFiles:\n; print_r($HTTP_POST_FILES); print /pre\n; ? form method='post' enctype='multipart/form-data' input type='text' name='section[0][firstname]' br input type='text' name='section[0][surname]' br input type='file' name='section[0][image]' br input type='submit' /form // ---end upload.php // ---start input -- section[0][firstname] = foo section[0][surname] = bar section[0][image] = ~/feathers.gif // ---end input // ---start output - Vars: Array ( [section] = Array ( [0] = 12409 ) ) Files: Array ( [section] = Array ( [0] = Array ( [name] = Array ( [image] = feathers.gif ) [type] = Array ( [image] = image/gif ) [tmp_name] = Array ( [image] = /tmp/phpwwJSPf ) [size] = Array ( [image] = 12409 ) ) ) ) // ---end output --- Edit this bug report at http://bugs.php.net/?id=9460edit=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]
[PHP-DEV] Bug #10800 Updated: File uploads take ~70 times longer than downloading files on Apache/PHP.
ID: 10800
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: HTTP related
Operating System: NT 2000
PHP Version: 4.0.5
New Comment:
This should be fixed in CVS now. You can try the latest
development build from http://www.php4win.com/ but
make sure it's dated after 27th of October 2001.
Also, there are some minor leaks still in the new code.
If you encounter such leaks, please send the shortest
possible code + html with which you can reproduce the leak
to [EMAIL PROTECTED] (or me) so we can get rid of these leaks.
This fix will be in PHP 4.2.0.
--Jani
Previous Comments:
[2001-08-08 12:30:02] [EMAIL PROTECTED]
I'm sorry it took so long in getting back Andy. Your question:
Could you please include the script that accepts the form
input and uploads the file (the ACTION param of the form.)
Here it is:
if (!$tmp_file = get_cfg_var('upload_tmp_dir')) {
$tmp_file = dirname(tempnam('', ''));
}
$tmp_file .= '/' . basename($userfile);
// Admin may have trailing slash in php.ini...
// Did it upload? */
if (ereg_replace('/+', '/', $tmp_file) == $userfile);
copy($userfile, $basedir/$name);
echo Success verbage goes here.;
} else {
echo Some kind of warning goes here.;
}
Thanks Andy,
Paul
[2001-08-07 12:27:00] [EMAIL PROTECTED]
status - feedback
[2001-07-21 21:46:17] [EMAIL PROTECTED]
Could you please include the script that accepts the form
input and uploads the file (the ACTION param of the form.)
-Andy
[2001-05-10 17:51:00] [EMAIL PROTECTED]
I logged this prior to PHP 4.0.5 and was told to do it again if it still occurs.
Please help:
ID: 9294
Updated by: andi
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Performance problem
PHP Version: 4.0.2
Assigned To:
Comments:
Please try PHP 4.0.4pl1 or 4.0.5 which is due out tomorrow and open a new bug report
if this still happens.
Previous Comments:
---
[2001-02-16 03:59:04] [EMAIL PROTECTED]
Sorry - I'm also using code like this to do the upload:
FORM ENCTYPE=multipart/form-data ACTION=_URL_ METHOD=POST
INPUT TYPE=hidden name=MAX_FILE_SIZE value=2
Send this file: INPUT NAME=userfile TYPE=file
INPUT TYPE=submit VALUE=Send File
/FORM
---
[2001-02-16 03:57:16] [EMAIL PROTECTED]
When performing a file upload, PHP runs the CPU to 100% and takes 3.5-4 minutes on
a Pentium III 850MHz CPU to upload a 10MB file when downloading the same file on
Apache/PHP only takes 3 seconds on the same host and client. It appears the file
is being parsed when being uploaded. Is there an option to tell PHP to upload the
data and nothing else? Otherwise, it is roughly 70 times slower to upload a file
than to download one.
I'm using Nusphere's CD when installing the software.
Edit this bug report at http://bugs.php.net/?id=10800edit=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]
[PHP-DEV] Bug #12845 Updated: server error when uploading more than 20 files once
ID: 12845 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Duplicate Status: Closed Bug Type: HTTP related Operating System: PHP Version: 4.0.6 New Comment: Fixed in CVS. --Jani Previous Comments: [2001-08-23 08:21:15] [EMAIL PROTECTED] Duplicate of #11998 [2001-08-23 06:47:36] [EMAIL PROTECTED] the system(s) are - Apache/1.3.12, PHP/4.0.6 on Linux (Redhat6.2) - Apache/1.3.19, PHP/4.0.6 on Linux (Redhat7.1) here the script does not work. switching to PHP/4.04pl on the same servers or using another liveserver with PHP/4.04pl lets the script work correctly. the upload.php consists of the following (summarized): form method=post action=? echo $PHP_SELF ? enctype=multipart/form-data input type=Hidden name=ID value=? echo $ID; ? input type=Hidden name=MAX_FILE_SIZE value=50 24+4 times input type=file name=PIC03b /form and after pressing the button, server hangs. michael [2001-08-20 19:44:17] [EMAIL PROTECTED] I can not reproduce this problem with my system: Linux (heavily customized RH 6.2) Apache 1.3.20 / mod_perl / PHP 4.0.7-dev / PHP 3.0.12 All compiled as DSO's. PHP 4.0.7-dev is the latest CVS. Almost every extension compiled into it... So what is your system? Web server? What is in upload.php ? --Jani [2001-08-20 05:22:27] [EMAIL PROTECTED] change to the last message. we switched again to 4.0.6 due to other problems with 4.04pl (nothing serious). the mentioned url links now to a non working version, we created a working one too: http://starkalender.de/bug/upload2.php [2001-08-20 04:18:04] [EMAIL PROTECTED] We installed the latest CVS and the problem still exists. The working example with 24++ files (using 4.04pl1 at the moment) can be found under http://starkalender.de/bug/upload.php . 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=12845 Edit this bug report at http://bugs.php.net/?id=12845edit=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]
[PHP-DEV] Bug #13029 Updated: Crash when uploading file whose size is 9 MB
ID: 13029 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: HTTP related Operating System: Windows 2000 professional PHP Version: 4.0.4pl1 New Comment: The http upload support has been rewritten in CVS now. You can try the latest development build from http://www.php4win.com/ but make sure it's dated after 27th of October 2001. (at the moment they don't have any builds there which have the fix) Also, there are some minor leaks still in the new code. If you encounter such leaks, please send the shortest possible code + html with which you can reproduce the leak to [EMAIL PROTECTED] (or me) so we can get rid of these leaks. This fix will be in PHP 4.2.0. --Jani Previous Comments: [2001-08-29 10:28:44] [EMAIL PROTECTED] I don't know mhy my posts are duplicated; i posted them once. [2001-08-29 10:18:43] [EMAIL PROTECTED] I don't know mhy my posts are duplicated; i posted them once. [2001-08-29 10:09:22] [EMAIL PROTECTED] I don't know mhy my posts are duplicated; i posted them once. [2001-08-29 10:08:08] [EMAIL PROTECTED] post_max_size is 180M [2001-08-29 09:55:18] [EMAIL PROTECTED] post_max_size is 180M 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=13029 Edit this bug report at http://bugs.php.net/?id=13029edit=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]
[PHP-DEV] Bug #13245 Updated: Hard 8Mb limit on file uploads?
ID: 13245 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: HTTP related Operating System: linux PHP Version: 4.0.6 New Comment: The http upload stuff has been rewritten in CVS. Try the latest CVS snapshot from http://snaps.php.net/ Also check the ulimit issue Hartmut mentioned. --Jani Previous Comments: [2001-10-23 11:23:36] [EMAIL PROTECTED] status - feedback [2001-10-06 08:12:44] [EMAIL PROTECTED] quick guess: process resource limits active? see man ulimit ... [2001-10-06 08:06:28] [EMAIL PROTECTED] yep, I have lots of times.. must be a memory limit somewhere in your system stopping PHP getting enough memory to perform the upload. can you try the exact settings jani said (the 16M ones) and lets see if that works. - James [2001-10-06 06:46:45] [EMAIL PROTECTED] Of course I did. Know of anybody who uploads more than 8Mb ? [2001-10-05 10:24:06] [EMAIL PROTECTED] You're the only one who experiences this 'bug' so I doubt it is a bug but only a misconfiguration. Did you or did you not set those directives I mentioned before? --Jani 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=13245 Edit this bug report at http://bugs.php.net/?id=13245edit=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]
[PHP-DEV] Bug #13405 Updated: Multiple File-Upload Problem
ID: 13405
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: HTTP related
Operating System:
PHP Version: 4.0.5
New Comment:
This should be fixed in CVS now. You can try the latest
development build from http://www.php4win.com/ but
make sure it's dated after 27th of October 2001.
Also, there are some minor leaks still in the new code.
If you encounter such leaks, please send the shortest
possible code + html with which you can reproduce the leak
to [EMAIL PROTECTED] (or me) so we can get rid of these leaks.
This fix will be in PHP 4.2.0.
--Jani
Previous Comments:
[2001-10-14 14:23:38] [EMAIL PROTECTED]
status: feeedback
[2001-10-14 14:15:40] [EMAIL PROTECTED]
IE6 Beta. I just upgraded to final release and will try again soon.
[2001-09-23 21:59:13] [EMAIL PROTECTED]
With which browser does this happen?
[2001-09-23 10:12:17] [EMAIL PROTECTED]
It's just like Bug #5836, but with the _name - Array. If you have a couple of files
to upload and the first is not set, then the array ${file._name} has only one key
(index 0) with the name of the second (!) file.
So when you loop through the file-array the wrong name is attached to the uploaded
file.
Following function solves the problem:
function correctFileUploadBug($fp_sVarName) {
GLOBAL ${$fp_sVarName}, ${$fp_sVarName._name};
$aFile = ${$fp_sVarName};
$aFileName = ${$fp_sVarName._name};
$aNewFileName = Array();
$j = 0;
for ($i=0;$icount($aFile);$i++) {
if (trim($aFile[$i]) == || trim($aFile[$i]) == none) {
$aNewFileName[] = ;
$j++;
} else {
$aNewFileName[] = $aFileName[$i-$j];
}
}
unset($aFile);
unset($aFileName);
${$fp_sVarName._name} = $aNewFileName;
}
Edit this bug report at http://bugs.php.net/?id=13405edit=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]
[PHP-DEV] Bug #13405 Updated: Multiple File-Upload Problem
ID: 13405
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: HTTP related
Operating System:
PHP Version: 4.0.5
New Comment:
You didn't mention with which system you run PHP in.
So if you do compile it yourself, get the latest
CVS snapshot from http://snaps.php.net/
Previous Comments:
[2001-10-28 17:12:43] [EMAIL PROTECTED]
This should be fixed in CVS now. You can try the latest
development build from http://www.php4win.com/ but
make sure it's dated after 27th of October 2001.
Also, there are some minor leaks still in the new code.
If you encounter such leaks, please send the shortest
possible code + html with which you can reproduce the leak
to [EMAIL PROTECTED] (or me) so we can get rid of these leaks.
This fix will be in PHP 4.2.0.
--Jani
[2001-10-14 14:23:38] [EMAIL PROTECTED]
status: feeedback
[2001-10-14 14:15:40] [EMAIL PROTECTED]
IE6 Beta. I just upgraded to final release and will try again soon.
[2001-09-23 21:59:13] [EMAIL PROTECTED]
With which browser does this happen?
[2001-09-23 10:12:17] [EMAIL PROTECTED]
It's just like Bug #5836, but with the _name - Array. If you have a couple of files
to upload and the first is not set, then the array ${file._name} has only one key
(index 0) with the name of the second (!) file.
So when you loop through the file-array the wrong name is attached to the uploaded
file.
Following function solves the problem:
function correctFileUploadBug($fp_sVarName) {
GLOBAL ${$fp_sVarName}, ${$fp_sVarName._name};
$aFile = ${$fp_sVarName};
$aFileName = ${$fp_sVarName._name};
$aNewFileName = Array();
$j = 0;
for ($i=0;$icount($aFile);$i++) {
if (trim($aFile[$i]) == || trim($aFile[$i]) == none) {
$aNewFileName[] = ;
$j++;
} else {
$aNewFileName[] = $aFileName[$i-$j];
}
}
unset($aFile);
unset($aFileName);
${$fp_sVarName._name} = $aNewFileName;
}
Edit this bug report at http://bugs.php.net/?id=13405edit=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]
[PHP-DEV] Bug #13585 Updated: nonsense code
ID: 13585
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: HTTP related
Operating System:
PHP Version: 4.0CVS-2001-10-07
New Comment:
Could you please explain also where this code fails?
If you have some short example script too, that would
help to see the whole picture.
--Jani
Previous Comments:
[2001-10-07 07:40:48] [EMAIL PROTECTED]
The following piece of code is taken from
SAPI.C/sapi_add_header_ex
it is obvious that this code is nonsense
a) *ptr will point to \0 because someone forgot to increase it (the while loop will
never be executed)
b) the second condition in the while loop is redundant
c) the size calculation should be done *after* the while loop
-
colon_offset = strchr(header_line, ':');
if (colon_offset) {
*colon_offset = 0;
if (!STRCASECMP(header_line, Content-Type)) {
char *ptr = colon_offset, *mimetype = NULL, *newheader;
size_t len = header_line_len - (ptr - header_line), newlen;
while (*ptr == ' ' *ptr != '\0') {
ptr++;
}
mimetype = estrdup(ptr);
--
Edit this bug report at http://bugs.php.net/?id=13585edit=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]
[PHP-DEV] Bug #10233 Updated: Big file uploading problem form HTML FORM
ID: 10233 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Duplicate Status: Closed Bug Type: Apache related Operating System: Window ME PHP Version: 4.0.4pl1 New Comment: This should be fixed in CVS now. You can try the latest development build from http://www.php4win.com/ but make sure it's dated after 27th of October 2001. Also, there are some minor leaks still in the new code. If you encounter such leaks, please send the shortest possible code + html with which you can reproduce the leak to [EMAIL PROTECTED] (or me) so we can get rid of these leaks. This fix will be in PHP 4.2.0. --Jani Previous Comments: [2001-04-09 02:47:41] [EMAIL PROTECTED] Duplicate of #10238 [2001-04-08 22:04:09] [EMAIL PROTECTED] REPLY to derick I have considered your comments that my script took more than 8MB of memory. But the same problem occurred. Exact error message from IE5.0 is Can not display this page. I think FORM HTML problem. What can I do ? ID: 10233 Updated by: derick Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: Apache related Assigned To: Comments: I don't think this is a bug, but that your script took more than 8MB of memory. Can you try changing your memory limit to a higher value? Previous Comments: --- [2001-04-08 07:11:16] [EMAIL PROTECTED] I try file uploading using Apache + PHP under WINDOW ME. I have set the my php.ini as following : ;;; ; Resource Limits ; ;;; PHPRC=C:/WINDOWS max_execution_time = 600 ; Maximum execution time of each script, in seconds memory_limit = 8M post_max_size = 100M ; File Uploads ; file_uploads= On; Whether to allow HTTP file uploads upload_tmp_dir = D:/temp upload_max_filesize = 100M I could upload file sized 5.96 MB but could not upload above filesize,5.96 MB. Maybe this is bug. Please e-mail to me with solutions. Good luck to you. [2001-04-08 07:26:03] [EMAIL PROTECTED] I don't think this is a bug, but that your script took more than 8MB of memory. Can you try changing your memory limit to a higher value? [2001-04-08 07:11:16] [EMAIL PROTECTED] I try file uploading using Apache + PHP under WINDOW ME. I have set the my php.ini as following : ;;; ; Resource Limits ; ;;; PHPRC=C:/WINDOWS max_execution_time = 600 ; Maximum execution time of each script, in seconds memory_limit = 8M post_max_size = 100M ; File Uploads ; file_uploads= On; Whether to allow HTTP file uploads upload_tmp_dir = D:/temp upload_max_filesize = 100M I could upload file sized 5.96 MB but could not upload above filesize,5.96 MB. Maybe this is bug. Please e-mail to me with solutions. Good luck to you. Edit this bug report at http://bugs.php.net/?id=10233edit=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]
[PHP-DEV] Bug #11056 Updated: file upload (size 1MB) takes too much time
ID: 11056 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Duplicate Status: Closed Bug Type: Apache related Operating System: Win98 PHP Version: 4.0.4pl1 New Comment: This should be fixed in CVS now. You can try the latest development build from http://www.php4win.com/ but make sure it's dated after 27th of October 2001. Also, there are some minor leaks still in the new code. If you encounter such leaks, please send the shortest possible code + html with which you can reproduce the leak to [EMAIL PROTECTED] (or me) so we can get rid of these leaks. This fix will be in PHP 4.2.0. Also check that your memory_limit, post_max_size and upload_max_filesize are big enough for the file. Only the memory_limit problem should be gone with this fix. --Jani Previous Comments: [2001-05-23 14:49:09] [EMAIL PROTECTED] Duplicate of #10800 [2001-05-23 11:47:08] [EMAIL PROTECTED] The same problem discribed in #10800: I'm using a simple upload-form to submit name, version and file to php-script. When filesize of the to be uploaded file is 4MB the upload tooks place in a few seconds! Greater files do exist in temp-directory a few seconds after submit-button in browser is hit BUT nevertheless more and more MB are submitted to the apache (which slowing down the system) and the PHP-file neither comes to an end nor produces a timeout... Thanks in advance for any hinds - with kind regards Torben Edit this bug report at http://bugs.php.net/?id=11056edit=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]
[PHP-DEV] Bug #5908 Updated: POST file uploading and HTTP_POST_VARS
ID: 5908 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Feature/Change Request Operating System: linux PHP Version: 4.0.0 New Comment: This propably has been fixed long time ago as we have HTTP_POST_FILES too. --Jani Previous Comments: [2000-08-01 20:04:36] [EMAIL PROTECTED] When using input type=file name=bob $bob is the temp file name. Wouldn't it stand to reason to put $bob in HTTP_POST_VARS too? If not, document it.. i went crazy for an hour with this =) Edit this bug report at http://bugs.php.net/?id=5908edit=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]
[PHP-DEV] Bug #7418 Updated: Mac WWW upload error FIX
ID: 7418
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: Feature/Change Request
Operating System: Any
PHP Version: 4.0.3pl1
New Comment:
This should be fixed in CVS now. You can try the latest
CVS snapshot from http://snaps.php.net/
Also, there are some minor leaks still in the new code.
If you encounter such leaks, please send the shortest
possible code + html with which you can reproduce the leak
to [EMAIL PROTECTED] (or me) so we can get rid of these leaks.
This fix will be in PHP 4.2.0.
--Jani
Previous Comments:
[2000-10-23 19:32:54] [EMAIL PROTECTED]
I found the following bit of code for removing the data fork from a file uploaded via
www by a Mac so that the file uploaded is usable. Trouble is it's in PERL and I want
to run it directly from PHP. So, my question is two fold:
1) Would it be possible for someone to translate it from PERL - PHP
2) Would it be possible to add this code into PHP to solve the Mac upload problem once
and for all?
Here's a copy of the code:
--
The following subroutine extracts the data fork (what most people would call the real
file contents) from the middle of the macbinary encapsulation (which also includes the
resource fork and some metadata like type and creator). I got this code off the net,
so if it's not entirely accurate, I'm sure one of you will tell me. Basically, the
first 128 bytes appears to be a header, and bytes 84 through 87 appear to be a
network-order integer value of how many bytes immediately following the header
constitute the datafork. So, with the right manipulation, I'm done.
sub strip_fork_from_fh {
my $fh = shift;
my $len = read $fh, (my $buf), 128; # read the header
die short read: $len unless $len == 128;
my $bytes = unpack(x83N, $buf); # get datafork length
read $fh, $buf, $bytes;
$buf;
}
You can view the article I found the code from at
http://www.stonehenge.com/merlyn/WebTechniques/col46.html
Edit this bug report at http://bugs.php.net/?id=7418edit=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]
[PHP-DEV] Bug #10049 Updated: Slashes passed thru a file upload
ID: 10049 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Feature/Change Request Operating System: Win98 / PWS 4.0 PHP Version: 4.0.4pl1 New Comment: This should be fixed in CVS now. You can try the latest development build from http://www.php4win.com/ but make sure it's dated after 27th of October 2001. Also, there are some minor leaks still in the new code. If you encounter such leaks, please send the shortest possible code + html with which you can reproduce the leak to [EMAIL PROTECTED] (or me) so we can get rid of these leaks. This fix will be in PHP 4.2.0. --Jani Previous Comments: [2001-03-29 03:55:30] [EMAIL PROTECTED] Maybe it's a not a bug but with Php 3.0.7 and PHP 4.0.2, when you upload a file, the file name is not stripslashed but in PHP4.0.4pl1, it is... That's confusing because I use a stripslashes function... Example : I upload c:\windows\toto.txt = PHP 3.0.8 and 4.0.2 : i get in the associated variable : c:\\windows\\toto.txt so I stripslash it... But in PHP 4.0.4pl1, i get c:\windows\toto.txt so when i stripslahs it, it can't find the file c:windowstoto.txt... I found a workaround but it's boring... That's all... Edit this bug report at http://bugs.php.net/?id=10049edit=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]
[PHP-DEV] Bug #12316 Updated: Have to increase memory_limit to be able to upload big files
ID: 12316 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Feature/Change Request Operating System: Linux PHP Version: 4.0.5 New Comment: This should be fixed in CVS now. You can try the latest snapshot from http://snaps.php.net/ Also, there are some minor leaks still in the new code. If you encounter such leaks, please send the shortest possible code + html with which you can reproduce the leak to [EMAIL PROTECTED] (or me) so we can get rid of these leaks. This fix will be in PHP 4.2.0. --Jani Previous Comments: [2001-07-23 09:01:30] [EMAIL PROTECTED] If you want to use file upload, you have to correctly set upload_max_size and post_max_size. That's o.k. But you also have to set memory_limit and max_execution_time to values high enough. The former seems to be result of very poor design (I admit I haven't checked the source code closely but as far as I can tell from a quick look at main/rfc1867.c, the whole form is first read and stored in memory and only then parsed and divided into files instead of being parsed on the run). I am not sure about the second issue since I don't know how exactly max_exec*_time works. Is it counted from the very start of request or from the moment script starts being executed? (that is -- if I set max_execution_time to 30 secs and the upload takes 55 secs, will PHP die? or will the upload finish and script will get 30secs to run?). I know I can get around this limit -- I just wonder. Edit this bug report at http://bugs.php.net/?id=12316edit=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]
[PHP-DEV] Bug #11323 Updated: thttpd+php4 upload bug with post-method
ID: 11323 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Other web server Operating System: FreeBSD3.2 PHP Version: 4.0 Latest CVS (2001-06-06) New Comment: Please report this to the kind folks of thttpd developers. --Jani Previous Comments: [2001-08-21 02:34:17] [EMAIL PROTECTED] Yes the same error, sorry... I am fear its thttpd, because there are no problems with Apache. Greetings, Dirk Brueggen -- Btw., what Operating-System do you use? ,-)) tar xzvf php4-200108200135.tar.gz cd php4-200108200135 ./configure --with-thttpd=../thttpd-2.21b/ --enable-wddx --enable-shared=no --enable-short-tags --without-mysql --without-pcre-regex make install --- out: ... + /usr/downloads/php4-200108200135/build/shtool install -c -m 644 /usr/downloads/php4-200108200135/pear/Log/observer.php /usr/local/lib/php/Log/ cp: /usr/downloads/php4-200108200135/pear/Log/observer.php: No such file or directory *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. Easyest Solution: cp or mv php4-200108200135/pear/Log/Observer.php php4-200108200135/pear/Log/observer.php OOOooohhh ,-)) Greetings, Dirk Brüggen. [2001-08-19 04:02:45] [EMAIL PROTECTED] Does this happen with latest CVS snapshot: http://snaps.php.net/ [2001-06-06 17:01:52] [EMAIL PROTECTED] Hello, on my(our) system(s), html-fileupload does not work with php4 and thttpd. It is not to see if it is a bug in php4 or in thttpd. I tested it with various versions of Php and Thttpd (see below). Sometime it works with the same php-scipts, but only with files under 600bytes and only with stunnel. The same scripts are running with Apache without errors. There are 2 kinds of error-syndromes: 1. The temp-file ($userfile, in my example below) and size ($userfile_size) does not exists, the variables are not generated=empty, but the file-name ($userfile_name) and mime-type ($userfile_type) are fine. This happened, if the upload-file was under 600bytes. 2. With bigger files, Netscape shows a network error: Broken pipe Anybody know the problem and can help me?? Maybe not enough stacksize? Resource limits (current): cputime infinity secs filesize infinity kb datasize 524288 kb stacksize 65536 kb coredumpsize infinity kb memoryuseinfinity kb memorylocked infinity kb maxprocesses 531 openfiles1064 Best regards, Dirk Brueggen --- Testet on Systems: FreeBSD 3.2 PHP4.0.6-dev Thttpd2.20bstunnel3.11 (works with small FreeBSD 3.2 PHP4.0.3pl1Thttpd2.20b files) FreeBSD 3.2 PHP4.0.5 Thttpd2.21 FreeBSD 3.2 PHP4.0.6-dev Thttpd2.19 FreeBSD 3.0 PHP4.0.3pl1Apache(Works fine!) --- Build with, one example: tar xzvf php4-latest_tar.tar tar xzvf thttpd-2.21.tar.gz cd php4-200104170045 ./configure --with-thttpd=../thttpd-2.21 or ./configure --with-thttpd=../thttpd-2.21 --enable-wddx or ./configure --with-thttpd=../thttpd-2.21 \ --enable-wddx --enable-shared=no \ --with-config-file-path=/usr/local/lib \ --enable-short-tags --without-mysql \ --without-pcre-regex make install cd ../thttpd-2.21 ./configure make make install -- I tested various php-settings, for example: max_execution_time=34 memory_limit=120 post_max_size=500 upload_tmp_dir=incoming/ upload_max_filesize=5000 -- Only for testing, I have siplified the php-scripts: uploadtest9.html - HTML HEAD TITLEUploadTest php4 V9.1/TITLE !-- Created by: Dirk Brueggen, 6.06.2001 -- BODY bgcolor=#e0e0e0 text=#00 link=#00b0ff vlink=#e1 alink=#8f BRBR H3Upload Test V9.1/H3 FORM ENCTYPE=multipart/form-data ACTION=uploadtest9.php METHOD=POST INPUT TYPE=hidden NAME=MAX_FILE_SIZE VALUE=100 Datei: INPUT NAME=userfile TYPE=file SIZE=50 BR INPUT TYPE=submit VALUE=File Senden /FORM /BODY /HTML -- uploadtest9.php --- HTML HEAD TITLEUploadTest php4 V9.1/TITLE !-- Created by: Dirk Brueggen, 6.06.2001 -- BODY bgcolor=e0e0e0 text=#00 link=#00b0ff vlink=#e1 alink=#8f BRBR HR H3Ergebniss/H3BR ?php set_time_limit(600); echo Tmp-File: $userfile BR; echo Original-Datei: $userfile_name BR; echo Groesse: $userfile_size BR; echo Mime: $userfile_type BR; $path1 = incoming/.$userfile_name; echo BRZiel: $path1 BR; copy($userfile,$path1); ? /BODY /HTML ---
[PHP-DEV] php and winxp
Hi! Is anyone tested PHP on Windows XP? If it is working correctly, we can add this platform to the lists at downloads.php and in the manual. Thanks, [EMAIL PROTECTED] [phpweb and phpdoc] -- 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]
[PHP-DEV] Echo vs in/out
I'm currently in the middle of a discussion with some fellow PHP developers regarding the speed of what we call in/out compared to echo. With in/out we mean stuff like this: // php code ? htmlsome html/html ?php // more php The manual states that PHP treats ??php as an echo statement, and I don't think there can be any speed difference between the two, however one of my fellow developers thinks there is a difference, and created a test which showed a 60% speed difference (using a for loop that ran 1 times). The test was badly executed IMO, so I ran my own which showed virtually no difference, but rather than getting into a flame-war I thought I'd just ask here for a quick answer. Is there a difference, and if so, is it significant? Regards André Næss -- 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]
[PHP-DEV] Bug #13860 Updated: Bzip2 bzdecompress function is wery slow...
ID: 13860 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Performance problem Operating System: Windows 98 SE PHP Version: 4.0.6 New Comment: you use bzdecompress(..., TRUE), i.e. you tell it to be two times slower... Then you shouldn't complain about performance, bzip is very strong compression at the cost of high memory and cpu usage. As I said in my comment I just tried what happen if I use the True parameter. I used the script without that parameter and it was slow... And you read the whole file in memory, decompress it, write it back to disk... that's very inefficient. Interesting. But I did the same in my older version of decompression script and it was fast... I dont sure why there is this differnece in the speed between the bzwrite() and the bzdecompress() functions. Btw I think I have a fast PC, a simple decompression like this should not take more than two or there secounds... Compressing JPG's is a quite useless practice by the way... jpg is already compressed. Of course I know jpg is already compressed... but this is a wery good way to test my script... If it works i can see the result immediately (the img at the and of the script). Is it satisfie you if I use pic.bmp next time? :) Previous Comments: [2001-10-28 16:27:24] [EMAIL PROTECTED] Please don't but multiple issues in one report, and keep your report short. (bugs do's and don'ts) I'm transforming this report into performance question of bzip, open a new feature/change request on the second parameter. you use bzdecompress(..., TRUE), i.e. you tell it to be two times slower... Then you shouldn't complain about performance, bzip is very strong compression at the cost of high memory and cpu usage. And you read the whole file in memory, decompress it, write it back to disk... that's very inefficient. So this is not a bug in PHP, but a problem with your script. Ask http://www.php.net/support.php for support questions on how to do things efficiently. Compressing JPG's is a quite useless practice by the way... jpg is already compressed. [2001-10-28 15:57:28] [EMAIL PROTECTED] bzdecompress($ecd_cont,1); I'm used it without the 1 parameter, i'm just tryed uot what happen if i use it... [2001-10-28 15:34:18] [EMAIL PROTECTED] I made a little decompresser script: ?php $efilename = d:/pic.bz2; //A compressed jpg image ( original size: 388kbyte, packed size: 388kbyte) $ufilename2 = d:/pic.jpg; $fp = fopen($efilename, rb); $ecd_cont = fread($fp, filesize($efilename)); //read the compressed data from file fclose($fp); $fp = fopen($ufilename2,wb); $ecd_cont = bzdecompress($ecd_cont,1); //decompress the readed compressed data fwrite($fp, $ecd_cont); //write the decompressed data into file fclose($fp); echo img src=\file://d:\\pic.jpg\; ? Ok, this is work... But it is WERY WERY slow!!! It's take 60sec to display the decompressed image, why?? I made the decompression befor with an other method: ?php $efilename = d:/pic.bz2; $ufilename2 = d:/pic.jpg; $bz = bzopen($efilename, rb); $ecd_cont = bzread($bz, 40); // See below bzlose($bz); $fp = fopen($ufilename2,wb); fwrite($fp, $ecd_cont); fclose($fp); echo img src=\file://d:\\pic.jpg\; ? Ok this is working (And this is fast! The decompressed picture appears immediately), but there is a little problem: In the PHP manual I read this about the bzread() function: If the optional parameter length is not specified, bzread() will read 1024 (uncompressed) bytes at a time. Ok, so it will read 1024 uncompressed bytes from my compressed file, if I not give the lenght parameter (as I did in the example). But there is a problem: if I want to be precise then I must give the lenght of the original file, but how??? I only have the compressed file, which is not equal with the original (ok, in my example it is, but only because the original jpg-compressed file), so I cant use the filesize() function, because it gave only the compressed filesize, neither the strlen() because I havnt got a string yet :) And I think you agree with me if I dont want to write 400Mbyte to parameter... this is not a correct solution. I think the correct solution if the bzread() function is read the entire file if I dont give the lenght parameter. Edit this bug report at http://bugs.php.net/?id=13860edit=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]
[PHP-DEV] Bug #13860 Updated: Bzip2 bzdecompress function is wery slow...
ID: 13860 Updated by: jeroen Reported By: [EMAIL PROTECTED] Old Status: Bogus Status: Assigned Bug Type: Performance problem Operating System: Windows 98 SE PHP Version: 4.0.6 Old Assigned To: Assigned To: jeroen New Comment: Reopened, the current implementation of bzdecompress is extremely inefficient. Assigned to myself. Previous Comments: [2001-10-28 20:01:28] [EMAIL PROTECTED] you use bzdecompress(..., TRUE), i.e. you tell it to be two times slower... Then you shouldn't complain about performance, bzip is very strong compression at the cost of high memory and cpu usage. As I said in my comment I just tried what happen if I use the True parameter. I used the script without that parameter and it was slow... And you read the whole file in memory, decompress it, write it back to disk... that's very inefficient. Interesting. But I did the same in my older version of decompression script and it was fast... I dont sure why there is this differnece in the speed between the bzwrite() and the bzdecompress() functions. Btw I think I have a fast PC, a simple decompression like this should not take more than two or there secounds... Compressing JPG's is a quite useless practice by the way... jpg is already compressed. Of course I know jpg is already compressed... but this is a wery good way to test my script... If it works i can see the result immediately (the img at the and of the script). Is it satisfie you if I use pic.bmp next time? :) [2001-10-28 16:27:24] [EMAIL PROTECTED] Please don't but multiple issues in one report, and keep your report short. (bugs do's and don'ts) I'm transforming this report into performance question of bzip, open a new feature/change request on the second parameter. you use bzdecompress(..., TRUE), i.e. you tell it to be two times slower... Then you shouldn't complain about performance, bzip is very strong compression at the cost of high memory and cpu usage. And you read the whole file in memory, decompress it, write it back to disk... that's very inefficient. So this is not a bug in PHP, but a problem with your script. Ask http://www.php.net/support.php for support questions on how to do things efficiently. Compressing JPG's is a quite useless practice by the way... jpg is already compressed. [2001-10-28 15:57:28] [EMAIL PROTECTED] bzdecompress($ecd_cont,1); I'm used it without the 1 parameter, i'm just tryed uot what happen if i use it... [2001-10-28 15:34:18] [EMAIL PROTECTED] I made a little decompresser script: ?php $efilename = d:/pic.bz2; //A compressed jpg image ( original size: 388kbyte, packed size: 388kbyte) $ufilename2 = d:/pic.jpg; $fp = fopen($efilename, rb); $ecd_cont = fread($fp, filesize($efilename)); //read the compressed data from file fclose($fp); $fp = fopen($ufilename2,wb); $ecd_cont = bzdecompress($ecd_cont,1); //decompress the readed compressed data fwrite($fp, $ecd_cont); //write the decompressed data into file fclose($fp); echo img src=\file://d:\\pic.jpg\; ? Ok, this is work... But it is WERY WERY slow!!! It's take 60sec to display the decompressed image, why?? I made the decompression befor with an other method: ?php $efilename = d:/pic.bz2; $ufilename2 = d:/pic.jpg; $bz = bzopen($efilename, rb); $ecd_cont = bzread($bz, 40); // See below bzlose($bz); $fp = fopen($ufilename2,wb); fwrite($fp, $ecd_cont); fclose($fp); echo img src=\file://d:\\pic.jpg\; ? Ok this is working (And this is fast! The decompressed picture appears immediately), but there is a little problem: In the PHP manual I read this about the bzread() function: If the optional parameter length is not specified, bzread() will read 1024 (uncompressed) bytes at a time. Ok, so it will read 1024 uncompressed bytes from my compressed file, if I not give the lenght parameter (as I did in the example). But there is a problem: if I want to be precise then I must give the lenght of the original file, but how??? I only have the compressed file, which is not equal with the original (ok, in my example it is, but only because the original jpg-compressed file), so I cant use the filesize() function, because it gave only the compressed filesize, neither the strlen() because I havnt got a string yet :) And I think you agree with me if I dont want to write 400Mbyte to parameter... this is not a correct solution. I think the correct solution if the bzread() function is read the entire file if I dont give the lenght parameter. Edit this bug report at http://bugs.php.net/?id=13860edit=1 -- PHP
Re: [PHP-DEV] Echo vs in/out
It has always been my understanding that in/out is faster as PHP does not
have to evalutate the terms for variables. The best test would be to use an
app like apache bench (aka: ab) against the two pages. Like this:
Test 1
---
?php
$var=array(1,2,3,4,5);
for($x=0;$x100;$x++){
echo Hello;
}
$var2=array(6,7,8,9,10);
?
results:
-
This is ApacheBench, Version 1.3c $Revision: 1.45 $ apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2000 The Apache Group, http://www.apache.org/
Server Software:Apache/1.3.20
Server Hostname:phorum.org
Server Port:80
Document Path: /~brian/test.php
Document Length:500 bytes
Concurrency Level: 3
Time taken for tests: 0.523 seconds
Complete requests: 100
Failed requests:0
Total transferred: 67830 bytes
HTML transferred: 51000 bytes
Requests per second:191.20
Transfer rate: 129.69 kb/s received
Connnection Times (ms)
min avg max
Connect:1 4 8
Processing:12 9 7
Total: 131315
Test 2
---
?php
$var=array(1,2,3,4,5);
for($x=0;$x100;$x++){
?Hello?php
}
$var2=array(6,7,8,9,10);
?
results:
-
This is ApacheBench, Version 1.3c $Revision: 1.45 $ apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2000 The Apache Group, http://www.apache.org/
Server Software:Apache/1.3.20
Server Hostname:phorum.org
Server Port:80
Document Path: /~brian/test1.php
Document Length:500 bytes
Concurrency Level: 3
Time taken for tests: 0.515 seconds
Complete requests: 100
Failed requests:0
Total transferred: 67830 bytes
HTML transferred: 51000 bytes
Requests per second:194.17
Transfer rate: 131.71 kb/s received
Connnection Times (ms)
min avg max
Connect:1 4 8
Processing:11 9 7
Total: 121315
---
So, as you can see, there is a difference but not that much. Perhaps if you
were echoing an entire page it would make a large difference. You should
read Nathan Wallace's paper PHP: Hackers Paradise Revisited
http://www.e-gineer.com/articles/php-hackers-paradise-revisited.phtml. In
it he talks about speed of coding and not speed of code. Take it with a
grain of salt but it is true. Sometimes it is more important how long it
takes to code something than it is how fast it runs. PHP makes it easy to
code fast while making sure the code runs fast enough.
Brian.
- Original Message -
From: Andre Næss [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, October 28, 2001 6:11 PM
Subject: [PHP-DEV] Echo vs in/out
I'm currently in the middle of a discussion with some fellow PHP
developers regarding the speed of what we call in/out compared to
echo. With in/out we mean stuff like this:
// php code
?
htmlsome html/html
?php
// more php
The manual states that PHP treats ??php as an echo statement, and I
don't think there can be any speed difference between the two, however one
of my fellow developers thinks there is a difference, and created a test
which showed a 60% speed difference (using a for loop that ran 1
times). The test was badly executed IMO, so I ran my own which showed
virtually no difference, but rather than getting into a flame-war I
thought I'd just ask here for a quick answer. Is there a difference, and
if so, is it significant?
Regards
André Næss
--
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]
--
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]
Re: [PHP-DEV] Echo vs in/out
As a matter of fact, going into and out of HTML blocks generates pretty
much the same intermediate code as echo does - echo is built into the
language at the very same level. If you use printf() or something like
that, though, you'll feel a significant difference.
That wasn't the case in PHP 3.0 (as far as I recall anyway, it's been a
while).
Zeev
On Sun, 28 Oct 2001, Brian Moon wrote:
It has always been my understanding that in/out is faster as PHP does not
have to evalutate the terms for variables. The best test would be to use an
app like apache bench (aka: ab) against the two pages. Like this:
Test 1
---
?php
$var=array(1,2,3,4,5);
for($x=0;$x100;$x++){
echo Hello;
}
$var2=array(6,7,8,9,10);
?
results:
-
This is ApacheBench, Version 1.3c $Revision: 1.45 $ apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2000 The Apache Group, http://www.apache.org/
Server Software:Apache/1.3.20
Server Hostname:phorum.org
Server Port:80
Document Path: /~brian/test.php
Document Length:500 bytes
Concurrency Level: 3
Time taken for tests: 0.523 seconds
Complete requests: 100
Failed requests:0
Total transferred: 67830 bytes
HTML transferred: 51000 bytes
Requests per second:191.20
Transfer rate: 129.69 kb/s received
Connnection Times (ms)
min avg max
Connect:1 4 8
Processing:12 9 7
Total: 131315
Test 2
---
?php
$var=array(1,2,3,4,5);
for($x=0;$x100;$x++){
?Hello?php
}
$var2=array(6,7,8,9,10);
?
results:
-
This is ApacheBench, Version 1.3c $Revision: 1.45 $ apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2000 The Apache Group, http://www.apache.org/
Server Software:Apache/1.3.20
Server Hostname:phorum.org
Server Port:80
Document Path: /~brian/test1.php
Document Length:500 bytes
Concurrency Level: 3
Time taken for tests: 0.515 seconds
Complete requests: 100
Failed requests:0
Total transferred: 67830 bytes
HTML transferred: 51000 bytes
Requests per second:194.17
Transfer rate: 131.71 kb/s received
Connnection Times (ms)
min avg max
Connect:1 4 8
Processing:11 9 7
Total: 121315
---
So, as you can see, there is a difference but not that much. Perhaps if you
were echoing an entire page it would make a large difference. You should
read Nathan Wallace's paper PHP: Hackers Paradise Revisited
http://www.e-gineer.com/articles/php-hackers-paradise-revisited.phtml. In
it he talks about speed of coding and not speed of code. Take it with a
grain of salt but it is true. Sometimes it is more important how long it
takes to code something than it is how fast it runs. PHP makes it easy to
code fast while making sure the code runs fast enough.
Brian.
- Original Message -
From: Andre Næss [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, October 28, 2001 6:11 PM
Subject: [PHP-DEV] Echo vs in/out
I'm currently in the middle of a discussion with some fellow PHP
developers regarding the speed of what we call in/out compared to
echo. With in/out we mean stuff like this:
// php code
?
htmlsome html/html
?php
// more php
The manual states that PHP treats ??php as an echo statement, and I
don't think there can be any speed difference between the two, however one
of my fellow developers thinks there is a difference, and created a test
which showed a 60% speed difference (using a for loop that ran 1
times). The test was badly executed IMO, so I ran my own which showed
virtually no difference, but rather than getting into a flame-war I
thought I'd just ask here for a quick answer. Is there a difference, and
if so, is it significant?
Regards
André Næss
--
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]
--
Zeev Suraski [EMAIL PROTECTED]
http://www.zend.com/
--
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]
[PHP-DEV] Bug #13860 Updated: Bzip2 bzdecompress function is wery slow...
ID: 13860 Updated by: jeroen Reported By: [EMAIL PROTECTED] Old Status: Assigned Status: Closed Bug Type: Performance problem Operating System: Windows 98 SE PHP Version: 4.0.6 Assigned To: jeroen New Comment: Fixed in CVS, will be in 4.2.0 Memory requirements are also lower now, as is for bzcompress. Previous Comments: [2001-10-28 20:31:25] [EMAIL PROTECTED] Reopened, the current implementation of bzdecompress is extremely inefficient. Assigned to myself. [2001-10-28 20:01:28] [EMAIL PROTECTED] you use bzdecompress(..., TRUE), i.e. you tell it to be two times slower... Then you shouldn't complain about performance, bzip is very strong compression at the cost of high memory and cpu usage. As I said in my comment I just tried what happen if I use the True parameter. I used the script without that parameter and it was slow... And you read the whole file in memory, decompress it, write it back to disk... that's very inefficient. Interesting. But I did the same in my older version of decompression script and it was fast... I dont sure why there is this differnece in the speed between the bzwrite() and the bzdecompress() functions. Btw I think I have a fast PC, a simple decompression like this should not take more than two or there secounds... Compressing JPG's is a quite useless practice by the way... jpg is already compressed. Of course I know jpg is already compressed... but this is a wery good way to test my script... If it works i can see the result immediately (the img at the and of the script). Is it satisfie you if I use pic.bmp next time? :) [2001-10-28 16:27:24] [EMAIL PROTECTED] Please don't but multiple issues in one report, and keep your report short. (bugs do's and don'ts) I'm transforming this report into performance question of bzip, open a new feature/change request on the second parameter. you use bzdecompress(..., TRUE), i.e. you tell it to be two times slower... Then you shouldn't complain about performance, bzip is very strong compression at the cost of high memory and cpu usage. And you read the whole file in memory, decompress it, write it back to disk... that's very inefficient. So this is not a bug in PHP, but a problem with your script. Ask http://www.php.net/support.php for support questions on how to do things efficiently. Compressing JPG's is a quite useless practice by the way... jpg is already compressed. [2001-10-28 15:57:28] [EMAIL PROTECTED] bzdecompress($ecd_cont,1); I'm used it without the 1 parameter, i'm just tryed uot what happen if i use it... [2001-10-28 15:34:18] [EMAIL PROTECTED] I made a little decompresser script: ?php $efilename = d:/pic.bz2; //A compressed jpg image ( original size: 388kbyte, packed size: 388kbyte) $ufilename2 = d:/pic.jpg; $fp = fopen($efilename, rb); $ecd_cont = fread($fp, filesize($efilename)); //read the compressed data from file fclose($fp); $fp = fopen($ufilename2,wb); $ecd_cont = bzdecompress($ecd_cont,1); //decompress the readed compressed data fwrite($fp, $ecd_cont); //write the decompressed data into file fclose($fp); echo img src=\file://d:\\pic.jpg\; ? Ok, this is work... But it is WERY WERY slow!!! It's take 60sec to display the decompressed image, why?? I made the decompression befor with an other method: ?php $efilename = d:/pic.bz2; $ufilename2 = d:/pic.jpg; $bz = bzopen($efilename, rb); $ecd_cont = bzread($bz, 40); // See below bzlose($bz); $fp = fopen($ufilename2,wb); fwrite($fp, $ecd_cont); fclose($fp); echo img src=\file://d:\\pic.jpg\; ? Ok this is working (And this is fast! The decompressed picture appears immediately), but there is a little problem: In the PHP manual I read this about the bzread() function: If the optional parameter length is not specified, bzread() will read 1024 (uncompressed) bytes at a time. Ok, so it will read 1024 uncompressed bytes from my compressed file, if I not give the lenght parameter (as I did in the example). But there is a problem: if I want to be precise then I must give the lenght of the original file, but how??? I only have the compressed file, which is not equal with the original (ok, in my example it is, but only because the original jpg-compressed file), so I cant use the filesize() function, because it gave only the compressed filesize, neither the strlen() because I havnt got a string yet :) And I think you agree with me if I dont want to write 400Mbyte to parameter... this is not a correct solution. I think the correct solution if the bzread() function is read the entire file
[PHP-DEV] Bug #11716 Updated: Segmentation fault(coredump) in Apache(DSO-enabled) startup
ID: 11716 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Open Bug Type: Apache related Operating System: AIX 4.3.3 PHP Version: 4.0.6 New Comment: I tried, however the result is same before. Tried snapshot : php4-200110281500.tar.gz $ pwd /home/cmlee/php4-200110281500 $ ./configure --enable-debug \ --with-apxs=/usr/local/apache/bin/apxs \ --with-mysql=no $ make ar -crlo .libs/libphp4.a .libs/libphp4.so.0 rm -fr .libs/libphp4.lax creating libphp4.la (cd .libs rm -f libphp4.la ln -s ../libphp4.la libphp4.la) make[1]: Leaving directory `/home/cmlee/php4-200110281500' Making all in pear make[1]: Entering directory `/home/cmlee/php4-200110281500/pear' make[1]: Leaving directory `/home/cmlee/php4-200110281500/pear' $ su # make install Making install in . make[1]: Entering directory `/home/cmlee/php4-200110281500' /home/cmlee/php4-200110281500/build/shtool mkdir -p /usr/local/apache/libexec /usr/local/apache/bin/apxs -S LIBEXECDIR=/usr/local/apache/libexec -i -a -n php4 libs/libphp4.so [activating module `php4' in /usr/local/apache/conf/httpd.conf] cp libs/libphp4.so /usr/local/apache/libexec/libphp4.so cp: libs/libphp4.so: No such file or directory apxs:Break: Command failed with rc=1 make[1]: *** [install-sapi] Error 1 make[1]: Leaving directory `/home/cmlee/php4-200110281500' make: *** [install-recursive] Error 1 # cp .libs/libphp4.so.0 /usr/local/apache/libexec/libphp4.so # cd /usr/local/apache/bin # ./httpd -X Segmentation fault (core dumped) # gdb httpd GNU gdb 4.18 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 powerpc-ibm-aix4.3.2.0... (gdb) run -X Starting program: /usr/locql/apache/bin/httpd -X /usr/lib/libpthreads.a: not in executable format: File format not recognized. (gdb) c Continuing. /usr/lpp/xlC/lib/libC.a: not in executable format: File format not recognized. (gdb) c Continuing. /usr/lib/libbind.a: not in executable format: File format not recognized. (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. 0xd0b5acac in ?? () from (unknown load module) (gdb) bt #0 0xd0b5acac in ?? () from (unknown load module) #1 signal handler called (gdb) quit Previous Comments: [2001-10-21 00:06:58] [EMAIL PROTECTED] Would you please try again the latest snapshot? [2001-07-19 00:56:34] [EMAIL PROTECTED] I tried to make php4-200107181935 snapshot. But now I have another problem which is an installation failure. $ ./configure --enable-debug \ --with-apxs=/home/apache/bin/apxs \ --with-mysql=no ... $ make ... $ su $ make install ... Making install in . make[1]: Entering directory `/home/cmlee/php4-200107181935' /home/cmlee/php4-200107181935/build/shtool mkdir -p /home/apache/libexec /home/apache/bin/apxs -S LIBEXECDIR=/home/apache/libexec -i -a -n php4 libs/libphp4.so [activating module `php4' in /home/apache/conf/httpd.conf] cp libs/libphp4.so /home/apache/libexec/libphp4.so cp: libs/libphp4.so: No such file or directory apxs:Break: Command failed with rc=1 make[1]: *** [install-sapi] Error 1 make[1]: Leaving directory `/home/cmlee/php4-200107181935' make: *** [install-recursive] Error 1 [2001-07-12 04:04:46] [EMAIL PROTECTED] Please try the latest CVS snapshot from http://snaps.php.net/ as #4630 was reported to be fixed now. [2001-06-26 21:52:10] [EMAIL PROTECTED] IBM AIX 4.3.3 Apache 1.3.20 PHP 4.0.6 Release GNU gcc 2.95.2 for AIX $ export CFLAGS=-g $ ./configure --enable-debug \ --with-apxs=/home/apache/bin/apxs \ --with-mysql=no ... $ make ... $ make install-sapi $ su # cd /home/apache/bin # ./httpd -X Segmentation fault (core dumped) # dbx httpd core Type 'help' for help. reading symbolic information ... [using memory image in core] Segmentation fault in php_if_apache_lookup_uri at 0xd14e5658 ($t1) 0xd14e5658 (php_if_apache_lookup_uri+0x554) 800clwz r0,0x0(r12) (dbx) where php_if_apache_lookup_uri() at 0xd14e5658 php_create_dir(??, ??) at 0xd14e6b28 ap_single_module_configure(0x2001b0a8, 0x2001b0d0, 0x200612a0) at 0x10018f8c load_module(0x2ff22620, 0x0, 0x2001c978, 0x2001c988) at 0x1006a974 invoke_cmd(0x20006d60, 0x2ff22620, 0x0, 0x2ff20600) at 0x10016738 ap_handle_command(0x2ff22620, 0x2001bc60, 0x2ff205d0) at 0x100175bc ap_srm_command_loop(0x2ff22620, 0x2001bc60) at
[PHP-DEV] Re: Bug #13853 Updated: undefined symbol: uncompress
Thank you very much, my lamp is on finally!! you guys are great!! mike From: Bug Database [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Bug #13853 Updated: undefined symbol: uncompress Date: 27 Oct 2001 21:26:51 - ID: 13853 Updated by: derick Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Compile Failure Operating System: Linux PHP Version: 4.0.4pl1 New Comment: Fixed in newer versions, add --with-zlib to configure to make it work for php 4.0.4 too. Derick Previous Comments: [2001-10-27 17:16:00] [EMAIL PROTECTED] Cleanly installed Red Hat 7.1 as a server from RH boxset Web Server installation delclined Compiled and installed MySQL 3.22.30 from source, okay, tested and verified installation Compiled and installed Apache_1.3.19, from source, okay, tested and verified installation downloaded and untarred php-4.0.4pl1 ran configure to mysql with path and to apxs with path ran make and make install, all went well, no errors configured httpd.conf (apache) to accept php, php4 extensions and made sure LoadModule php4_module and libexec/libphp4.so were present and uncommented tried to start apache again and got the error: cannot load/usr/src/apache_1.3.19/libexec/libphp4.so into server undefined symbol: uncompress made sure zlib was loaded and it was per prior bug report error still occurs, apache will not start, ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=13853edit=2 _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp -- 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]
[PHP-DEV] Re: Echo vs in/out
Andre næss wrote:
I'm currently in the middle of a discussion with some fellow PHP
developers regarding the speed of what we call in/out compared to
echo. With in/out we mean stuff like this:
// php code
?
htmlsome html/html
?php
// more php
The manual states that PHP treats ??php as an echo statement, and I
don't think there can be any speed difference between the two, however one
of my fellow developers thinks there is a difference, and created a test
which showed a 60% speed difference (using a for loop that ran 1
times). The test was badly executed IMO, so I ran my own which showed
virtually no difference, but rather than getting into a flame-war I
thought I'd just ask here for a quick answer. Is there a difference, and
if so, is it significant?
Just try following 2 scripts
=== script1 ===
?php
for($i=0; $i 5; $i++) {
echo 'abcderfghjklmn
';
}
?
=== end ===
=== script2 ===
?php
for($i=0; $i 5; $i++) {
?
abcderfghjklmn
?php
}
?
=== end ===
There is not much difference, but script1 is just a little faster
on my system.
--
Yasuo Ohgaki
--
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]
[PHP-DEV] Re: php and winxp
Hojtsy Gabor wrote: Is anyone tested PHP on Windows XP? Yes, it works fine. I have tested Apache 2.0.27-dev, PHP 4.2.0-dev and MySQL 3.23.41 on my notebook (where I have a Windows XP Professional installation) recently. If it is working correctly, we can add this platform to the lists at downloads.php and in the manual. Sure, go ahead. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- 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]
[PHP-DEV] Bug #12426 Updated: Critical PHP bug while processing big POST data (10K)
ID: 12426 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: HTTP related Operating System: RedHat Linux 7.0 2.2.16-22smp PHP Version: 4.0.6 New Comment: Propably your patching had gone too far? :) The HTTP upload is rewritten now in CVS. You could try the latest CVS snapshot from http://snaps.php.net/ And also get fresh sources of Apache too. --Jani Previous Comments: [2001-08-02 21:16:49] [EMAIL PROTECTED] Oh, you are right, Rasmus! Thanks a lot. I tried to set Russian Apache 1.3.20 (my old version was 1.3.14) and test PHP under it. Big POST transfer works correctly! But then my Apache had died (oh, too many made-by-hand patches, iI think), it is only my problem, I suppose. But I do not understand, why PHP3 works correctly, but PHP4 does not?.. [2001-08-02 19:46:57] [EMAIL PROTECTED] Must be something related to that russian module you have loaded in your Apache [2001-08-02 19:16:24] [EMAIL PROTECTED] Well, some days ago I had tried to patch PHP myself. No result :-( I have found that PHP does not get POST data larger than about 4000 bytes (3996). There is a constant in SAPI.h: #define SAPI_POST_BLOCK_SIZE 4000 I understand that this constant explains the block size, which is used by PHP to read data from stdin in function: SAPI_POST_READER_FUNC(sapi_read_standard_form_data) in SAPI.c. It is very VERY weird, but when I set SAPI_POST_BLOCK_SIZE to, for example, 1, POST data is cutted by 4000 bytes again (not 1, as I expected)! It looks like there is no bug in block-oriented algorythm of POST reading, but then why 4000?.. PS: you think that it is HTTP-related bug? I don't think so: PHP3 works correctly... [2001-07-27 10:57:49] [EMAIL PROTECTED] I have configured PHP4 to process POST data less than 800 (phpinfo() reports that, see below). When I use the following script and enter a large block of text in the form, PHP4 cuts it off. Please test http://www.dklab.ru/test.php (with phpinfo() call, form at the bottom of the file) http://dklab.ru/content.txt (the file I am inserting - please test it) Here is the script: ? show_source(test.php); echo @$text; ? form action=test.php method=post textarea cols=60 rows=10 name=text wrap=virtual ?$f=fopen(content.txt,r); echo fread($f,10)? /textareabr input type=submit name=go value=Go! /form I have encountered that use of multipart/form-data forms solves this problem, but usual POST forms does not work correctly. PHP3 also work correct with such forms. Edit this bug report at http://bugs.php.net/?id=12426edit=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]
[PHP-DEV] Bug #13846 Updated: Patch: Use [ ] as shortcut for array()
ID: 13846
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: Feature/Change Request
Operating System: Any
PHP Version: 4.0.6
New Comment:
We are not going to make PHP as obscure as Perl is.
--Jani
Previous Comments:
[2001-10-27 02:49:25] [EMAIL PROTECTED]
My browser mangling the patch see if these works
--- php-4.0.6/Zend/zend_language_parser.y.zak Sun May 6 21:36:25 2001
+++ php-4.0.6/Zend/zend_language_parser.y Sat Oct 27 11:20:06 2001
@@ -481,6 +481,7 @@
| '@' { zend_do_begin_silence($1 CLS_CC); } expr {
zend_do_end_silence($1 CLS_CC); $$ = $3; }
| scalar { $$ = $1; }
| T_ARRAY '(' array_pair_list ')' { $$ = $3; }
+ | '[' array_pair_list ']' { $$ = $2; }
| '`' encaps_list '`' { zend_do_shell_exec($$, $2 CLS_CC);
}
| T_PRINT expr { zend_do_print($$, $2 CLS_CC); }
;
@@ -533,6 +534,7 @@
| '+' static_scalar { $$ = $1; }
| '-' static_scalar { zval minus_one; minus_one.type = IS_LONG;
minus_one.value.lval = -1; mul_function($2.u.constant, $2.u.constant, minus_one);
$$ = $2; }
| T_ARRAY '(' static_array_pair_list ')' { $$ = $3; $$.u.constant.type =
IS_CONSTANT_ARRAY; }
+ | '[' static_array_pair_list ']' { $$ = $2; $$.u.constant.type =
+IS_CONSTANT_ARRAY; }
;
[2001-10-27 02:42:21] [EMAIL PROTECTED]
In my script I use a lot of nested array() or array() as
parameter. So the array() things start to get in the way.
I assume many PHP programmer feels the same thing.
We need a short version of array() construct, and I think
the [] is the best choice. It is used in python and ruby.
After a little bit trying I finally could make a patch and
make it work on my server.
I hope this patch will find its way to official php soon.
WARNING:
I'm new in this whole bison C thing so I maybe making some
silly mistake.
--- php-4.0.6/Zend/zend_language_parser.y.zak Sun May 6 21:36:25 2001
+++ php-4.0.6/Zend/zend_language_parser.y Sat Oct 27 11:20:06 2001
@@ -481,6 +481,7 @@
|
'@' { zend_do_begin_silence($1 CLS_CC); } expr {
zend_do_end_silence($1 CLS_CC); $$ = $3; }
|
scalar
{ $$ = $1; }
|
T_ARRAY '(' array_pair_list ')' { $$ = $3; }
+
|
'[' array_pair_list ']' { $$ = $2; }
|
'`' encaps_list '`' { zend_do_shell_exec($$, $2 CLS_CC); }
|
T_PRINT expr { zend_do_print($$, $2 CLS_CC); }
;
@@ -533,6 +534,7 @@
|
'+' static_scalar { $$ = $1; }
|
'-' static_scalar { zval minus_one; minus_one.type = IS_LONG;
minus_one.value.lval = -1; mul_function($2.u.constant,
$2.u.constant, minus_one); $$ = $2; }
|
T_ARRAY '(' static_array_pair_list ')' { $$ = $3;
$$.u.constant.type = IS_CONSTANT_ARRAY; }
+
|
'[' static_array_pair_list ']' { $$ = $2; $$.u.constant.type
= IS_CONSTANT_ARRAY; }
;
Edit this bug report at http://bugs.php.net/?id=13846edit=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]
[PHP-DEV] Bug #11025 Updated: ftp_connect() does not work with IP address
ID: 11025
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Duplicate
Status: Feedback
Bug Type: FTP related
Operating System: Windows NT4 Server
PHP Version: 4.0.5
New Comment:
status - feedback
Previous Comments:
[2001-07-22 06:18:45] [EMAIL PROTECTED]
I think this is just like bug #11000. Could you test
fopen with ftp or http as well? If that works for you
I think I know how to make ftp_connect() work as well.
For more info, see what I wrote for bug #11000.
[2001-07-21 21:35:08] [EMAIL PROTECTED]
Whoa! This is exactly the OPPOSITE of what I expected.
Usually in something like this, the IP works, and the name
doesn't. I have no clue what would cause that. Can anyone
duplicate this?
[2001-05-22 13:34:53] [EMAIL PROTECTED]
Setup:
Windows NT4 Server with Apache 39 and PHP 4.0.5 as downloaded (big package) from
PHP.NET
Situation:
phpInfo() says FTP is enabled.
ftp_connect('192.168.0.55') does not give connection handle whereas an ftp client on
the same machine works perfectly. Tried all kinds of quotes, no success.
Solution:
Entered a line in local hosts lookup file to replace the IP with a literal name.
Replaced the faulty line with
ftp_connect(theName)
and got the connection right away.
Edit this bug report at http://bugs.php.net/?id=11025edit=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]
[PHP-DEV] Bug #8579 Updated: text files do not have \r\n translation from \n
ID: 8579 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Filesystem function related Operating System: windows 2000 Pro, IIS 5 PHP Version: 4.0.4 New Comment: PHP uses the system provided fwrite. If that does not work, it's not PHP problem. --Jani Previous Comments: [2001-01-25 19:22:57] [EMAIL PROTECTED] Cynic pointed out that I was misreading this bug report. PHP's fwrite doesn't seem to do the same translation that C does on windows boxes. [2001-01-25 18:37:36] [EMAIL PROTECTED] This is not really a bug. PHP emulates C in this, as it does in many other things. It seems that in the opinion of most of the developers, this is a Good Thing (tm). Reclassify as a Change Request. [2001-01-08 20:33:05] [EMAIL PROTECTED] The problem is not with fopen(file, wb), which works correctly. The problem is with fopen(file, w) because it works the same as the wb option. Using the w option should cause any text to be translated from '\n' to '\r\n' on Windows systems or else text editors such as Notepad will not view the file correctly. [2001-01-08 14:04:13] [EMAIL PROTECTED] fopen uses whatever mode you give it. The rest of functions (like system) use 'b' modes, since they are meant to pass the data unchanged. If you have a code that uses fopen and it ignores 'b', please reopen the report and post the code, otherwise - you are getting the intended behaviour. [2001-01-07 14:11:54] [EMAIL PROTECTED] C programs that execute on Windows systems use fopen() with a b mode option (example, fopen(fname,wb)) when the output string is to be written exactly as is to the file. When opened with w, the '\n' character is automatically translated to the sequence '\r\n'. This character sequence defines the end of lines to Windows-based text programs, such as Notepad. This capability is not supported with PHP though the documentation hints that it should. Without this feature, PHP programs are not directly portable between Windows systems and Unix/Linux systems without a lot of special program coding on the part of the developer. Edit this bug report at http://bugs.php.net/?id=8579edit=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]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c
On Sun, 28 Oct 2001, Zeev Suraski wrote: Modified files: /php4/ext/standardbasic_functions.c Log: Whitespace fixes Don't Adafy the code, Jani :) eeew... I guess I like Ada then... Derick -- 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]
[PHP-DEV] Bug #9208 Updated: rename() not using current working directory
ID: 9208
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: Filesystem function related
Operating System: windows 98
PHP Version: 4.0.4pl1
New Comment:
Does this fail with PHP 4.0.6 too?
Previous Comments:
[2001-02-10 17:04:00] [EMAIL PROTECTED]
rename() function does not use current working directory, but c:\php\ instead (on
windows system)
so if I use rename('a','b') from any directory, it will try to rename c:\php\a to
c:\php\b
Edit this bug report at http://bugs.php.net/?id=9208edit=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]
[PHP-DEV] Bug #9846 Updated: fopen() fails and gives Error 0 on NoContent URLs
ID: 9846 Updated by: sniper Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Filesystem function related Operating System: linux,irix,tru64 PHP Version: 4.0.4pl1 New Comment: Taken from #9847, these are basically the same problem: When fopen()-ing an URL that responds with an HTTP 403 Forbidden, fopen() fails with an Error 0. There is no way to distinguish this error from a 'Not Found' type of error. --- Previous Comments: [2001-03-19 16:56:02] [EMAIL PROTECTED] This bug might belong in the URL-related section. I believe it to be a generic problem. If you fopen() an URL that returns with an HTTP Header of NoContent (204), fopen() will fail with Error 0. Failure would be ok if there was a specific error code for NoContent URLs. Either that or returning a handle that was already at eof would suffice. As it is now, there's no way to tell the difference between a bad (NotFound) URL and a NoContent URL. Work-around it to use cURL to a temporary file and check the HTTP_CODE with the undocumented curl_getinfo() function. Of course, it seems a little weird to require the temporary file for a NoContent URL. But it works fine. -Eric Bloch [EMAIL PROTECTED] Edit this bug report at http://bugs.php.net/?id=9846edit=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]
[PHP-DEV] Bug #9787 Updated: redirecting php-cgi stderr does not affect php://stderr
ID: 9787 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: Filesystem function related Operating System: SCO Openserver5 (Any UNIX?) PHP Version: 4.0.4pl1 New Comment: First of all, does this happen with PHP 4.0.6? Also, please explain HOW it affects it? Previous Comments: [2001-03-16 10:26:25] [EMAIL PROTECTED] Redirecting php-cgi stderr when invoking a php script from the command line (as in 'myscript.php 2error.log') does not affect writing data to php://stderr, but it does affect writing to /dev/stderr. Edit this bug report at http://bugs.php.net/?id=9787edit=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]
[PHP-DEV] Bug #9847 Updated: fopen() fails with Error 0 on Forbidden URLs
ID: 9847 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: Filesystem function related Operating System: PHP Version: 4.0.4pl1 New Comment: Moved this information into #9846, no use to have two reports about same problem. Previous Comments: [2001-03-19 16:59:04] [EMAIL PROTECTED] Perhaps this belongs in the URL related functions. When fopen()-ing an URL that responds with an HTTP 403 Forbidden, fopen() fails with an Error 0. There is no way to distinguish this error from a 'Not Found' type of error. Workaround is to use cURL. Eric Edit this bug report at http://bugs.php.net/?id=9847edit=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]
[PHP-DEV] Bug #9847 Updated: fopen() fails with Error 0 on Forbidden URLs
ID: 9847 Updated by: sniper Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Filesystem function related Operating System: PHP Version: 4.0.4pl1 New Comment: This information moved to #9846. No need for two reports about same issue. Previous Comments: [2001-10-29 02:37:58] [EMAIL PROTECTED] This information moved to #9846. No need for two reports about same issue. [2001-10-29 02:37:17] [EMAIL PROTECTED] Moved this information into #9846, no use to have two reports about same problem. [2001-03-19 16:59:04] [EMAIL PROTECTED] Perhaps this belongs in the URL related functions. When fopen()-ing an URL that responds with an HTTP 403 Forbidden, fopen() fails with an Error 0. There is no way to distinguish this error from a 'Not Found' type of error. Workaround is to use cURL. Eric Edit this bug report at http://bugs.php.net/?id=9847edit=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]
[PHP-DEV] Bug #10439 Updated: relative chdir from root doesn´t work
ID: 10439 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Filesystem function related Operating System: W98, W98SE PHP Version: 4.0.5 New Comment: Reopen if this happens with PHP 4.0.6. Also, try not to out-smart PHP's functions. They should know how to handle different path separators and such things which are platform specific. --Jani Previous Comments: [2001-05-02 16:34:59] [EMAIL PROTECTED] asp-mssql [2001-05-02 16:34:04] [EMAIL PROTECTED] Sorry, my only win2000 system is an asp-mysql production system in a network center and not available for testing now. I will install php on this system maybe in two weeks. [2001-05-02 16:29:17] [EMAIL PROTECTED] Do you happen to have an NT machine you can try and reproduce this on? I am on Windows 2000 and it works. [2001-05-02 16:24:44] [EMAIL PROTECTED] No, new version 4.0.5 didn't solve my problem, testesd under win98. [2001-04-30 09:35:24] [EMAIL PROTECTED] Works fine in latest CVS under NT. Please try 4.0.5 which should be released today and report back if your problem has been solved. 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=10439 Edit this bug report at http://bugs.php.net/?id=10439edit=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]
[PHP-DEV] Bug #9847 Updated: fopen() fails with Error 0 on Forbidden URLs
ID: 9847 Updated by: sniper Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Filesystem function related Operating System: PHP Version: 4.0.4pl1 New Comment: This information moved to #9846. No need for two reports about same issue. Previous Comments: [2001-10-29 02:37:17] [EMAIL PROTECTED] Moved this information into #9846, no use to have two reports about same problem. [2001-03-19 16:59:04] [EMAIL PROTECTED] Perhaps this belongs in the URL related functions. When fopen()-ing an URL that responds with an HTTP 403 Forbidden, fopen() fails with an Error 0. There is no way to distinguish this error from a 'Not Found' type of error. Workaround is to use cURL. Eric Edit this bug report at http://bugs.php.net/?id=9847edit=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]
[PHP-DEV] Bug #10482 Updated: if the filesize if more than 2GB, filesystem functions do not seem to recognize
ID: 10482
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: Filesystem function related
Operating System: redhat 7.1
PHP Version: 4.0.4pl1
New Comment:
32 bit=2GB limitation in the ext2 for files.
Not a PHP problem.
--Jani
Previous Comments:
[2001-04-24 20:14:21] [EMAIL PROTECTED]
$folder = dir(.);
$folder-rewind() ;
clearstacache();
while ($file=$folder-read()) {
if (is_dir ($file)) {
do_some thing...
}
elif (is_file($file)) {
do_somethingelse.
}
..
.
}
is_file() call in the above code does not return ture if the file size is 2GB.
I was able to print $file, just inside the loop (meaning the folder object has the
file in the filelist
and hence it is the is_file() which is filtering it out.
I tried other functions like file_exists(), is_readable() etc in place of is_file()
without any success.
Edit this bug report at http://bugs.php.net/?id=10482edit=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]
[PHP-DEV] Bug #13816 Updated: Accessing a static HTML page crashes Apache
ID: 13816 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Open Bug Type: Reproducible crash Operating System: Solaris 8 SPARC PHP Version: 4.0.6 New Comment: No crash when Apache is configured without mod_perl. Previous Comments: [2001-10-28 11:50:21] [EMAIL PROTECTED] Try removing mod_perl and see if it works then. --Jani [2001-10-27 06:03:04] [EMAIL PROTECTED] Did you do 'apachectl stop ; apachectl start' ?? Restart won't work. --Jani [2001-10-24 13:17:56] [EMAIL PROTECTED] Config: Apache 1.3.22, mod_perl 1.26 with perl 5.6.1, PHP 4.0.6, Sun E250, Solaris 8 PHP configured with apxs like this: ./configure --verbose --prefix=/opt/OCTOapache-1.3.22 --datadir=/opt/OCTOapache-1.3.22/lib --exec-prefix=/opt/OCTOapache-1.3.22 --libexecdir=/opt/OCTOapache-1.3.22/helpers --localstatedir=/opt/OCTOapache-1.3.22/lib --enable-sysvsem -enable-sysvshm --with-ndbm --with-yp --with-ldap=/opt/local/sparc --with-mysql=/opt/OCTOmysql --enable-shmop --with-exec-dir=/opt/OCTOapache-1.3.22/safe-exec --with-config-file-path=/opt/OCTOapache-1.3.22/conf/php3.ini --enable-safe-mode --with-apxs=/opt/OCTOapache-1.3.22/bin/apxs Just doing a HEAD request on / crashes Apache if libphp4.so is loaded: LoadModule php4_modulelibexec/libphp4.so AddModule mod_php4.c telnet localhost 8088 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. HEAD / HTTP/1.0 Connection closed by foreign host. This is the tail of the systemcall trace from truss: 11140: stat64(/opt/OCTOapache-1.3.22/htdocs/index.html.ru.iso-ru, 0x002E3908) = 0 11140: stat64(/opt/OCTOapache-1.3.22/htdocs/index.html.ru.koi8-r, 0x002E3908) = 0 11140: stat64(/opt/OCTOapache-1.3.22/htdocs/index.html.ru.ucs2, 0x002E3908) = 0 11140: stat64(/opt/OCTOapache-1.3.22/htdocs/index.html.ru.ucs4, 0x002E3908) = 0 11140: stat64(/opt/OCTOapache-1.3.22/htdocs/index.html.ru.utf8, 0x002E3908) = 0 11140: getdents64(7, 0x0028C018, 1048) = 128 11140: stat64(/opt/OCTOapache-1.3.22/htdocs/index.html.se, 0x002E3908) = 0 11140: stat64(/opt/OCTOapache-1.3.22/htdocs/index.html.zh.Big5, 0x002E7908) = 0 11140: getdents64(7, 0x0028C018, 1048) = 0 11140: close(7)= 0 11140: stat64(/opt/OCTOapache-1.3.22/htdocs/index.html.en, 0x002A7500) = 0 11140: Incurred fault #6, FLTBOUNDS %pc = 0xFF05990C 11140:siginfo: SIGSEGV SEGV_MAPERR addr=0x005C 11140: Received signal #11, SIGSEGV [default] 11140:siginfo: SIGSEGV SEGV_MAPERR addr=0x005C 11140: *** process killed *** And this is the stack when the crash happens: core file = /opt/OCTOapache-1.3.22/core -- program ``httpd'' on platform SUNW,Ultra-250 SIGSEGV: Segmentation Fault $C yy_get_next_buffer(0x1aafd8,0x1a2818,0x2,0x0,0x0,0x0) + 21c [savfp=0xffbef830,savpc=0x7555c] ap_clear_pool(0x1a2818,0x1a6818,0x0,0x0,0x0,0x0) + 4c [savfp=0xffbef8a0,savpc=0x755ec] ap_destroy_pool(0x1a2818,0x19e818,0x0,0xff238018,0xffbeda11,0x0) + 14 [savfp=0xffbef910,savpc=0x75544] ap_clear_pool(0x19e818,0xff23fa9c,0x0,0xa,0x0,0xffbed9d0) + 34 [savfp=0xffbef980,savpc=0x755ec] ap_destroy_pool(0x19e818,0x19a9a0,0xd,0x1a2840,0x0,0x16ca98) + 14 [savfp=0xffbef9f0,savpc=0x8b0b8] clean_parent_exit(0x0,0x13d2,0xd,0x1a2840,0x16ca98,0x16c800) + 14 [savfp=0xffbefa60,savpc=0x8f044] standalone_main(0x1,0xffbefbfc,0x0,0x0,0xff23b03c,0x16cb58) + 764 [savfp=0xffbefae8,savpc=0x8f824] main(0x1,0xffbefbfc,0xffbefc04,0x19b5f4,0x0,0x0) + 51c [savfp=0xffbefb98,savpc=0x2a320] When I comment out the LoadModule and the AddModule line, the HEAD request is OK: telnet localhost 8088 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. HEAD / HTTP/1.0 HTTP/1.1 200 OK Date: Wed, 24 Oct 2001 17:14:57 GMT Server: Apache/1.3.22 (Unix) mod_perl/1.26 Last-Modified: Fri, 04 May 2001 00:00:38 GMT ETag: 398ee-5b0-3af1f126 Accept-Ranges: bytes Content-Length: 1456 Connection: close Content-Type: text/html Content-Language: en Connection closed by foreign host. I had PHP 4.0.4pl1 running OK with the same apache. This happened after I compiled 4.0.6 with the same configuration and installed it over 4.0.4pl1. Edit this bug report at http://bugs.php.net/?id=13816edit=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]
