php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #24080 fputs uses 100% cpu on broken pipe
Submitted: 2003-06-08 07:04 UTC Modified: 2003-09-11 01:08 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:0 (0.0%)
From: info at virtualhost dot nl Assigned: wez (profile)
Status: Closed Package: URL related
PHP Version: 4.3.2 OS: Freebsd 4.8
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
24 - 12 = ?
Subscribe to this entry?

 
 [2003-06-08 07:04 UTC] info at virtualhost dot nl
hello,

When executing the following code, the httpd deamon consumes all cpu available, which should not happen of course. It's stops when the timeout of the script is reached and the process is deleted.

<?
$sk = fsockopen ('211.6.149.130', 80);
if ($sk) {
 fputs  ($sk, "GET /blalbla HTTP/1.0\n\n");
}
?>

btw. When requested with curl it says directly 'broken pipe'.
btw2. Same for fwrite.

regards,

Jeroen

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-06-08 07:09 UTC] wez@php.net
Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP -- 
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php

If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.

.
 [2003-06-08 08:06 UTC] info at virtualhost dot nl
Same problem with version 4.3.2. But cpu usage is divided differenty. 4.3.1 used about 50% users / 50% system now it is 90% user / 10% sytem.
 [2003-06-08 08:18 UTC] wez@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

Please interrupt it once it has started eating the CPU and provide a backtrace.
 [2003-06-09 15:37 UTC] info at virtualhost dot nl
ok, took some time, but here it is:

Program received signal SIGPIPE, Broken pipe.
0x280ff604 in sendto () from /usr/lib/libc.so.4

#0  0x280ff604 in sendto () from /usr/lib/libc.so.4
#1  0x2812798b in send () from /usr/lib/libc.so.4
#2  0x282b00cb in php_sockop_write (stream=0x809070c, buf=0x815f48c "GET /blalbla HTTP/1.0\n\n", count=23)
    at /usr/src/php/php-4.3.2/main/network.c:913
#3  0x282ace63 in _php_stream_write (stream=0x809070c, buf=0x815f48c "GET /blalbla HTTP/1.0\n\n", count=23)
    at /usr/src/php/php-4.3.2/main/streams.c:909
#4  0x2824741f in zif_fwrite (ht=2, return_value=0x815d62c, this_ptr=0x0, return_value_used=0)
    at /usr/src/php/php-4.3.2/ext/standard/file.c:1559
#5  0x282dd368 in execute (op_array=0x815e90c) at /usr/src/php/php-4.3.2/Zend/zend_execute.c:1608
#6  0x282cbada in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/php/php-4.3.2/Zend/zend.c:869
#7  0x282a4129 in php_execute_script (primary_file=0xbfbff9c4) at /usr/src/php/php-4.3.2/main/main.c:1671
#8  0x282e3da2 in apache_php_module_main (r=0x815a034, display_source_mode=0)
    at /usr/src/php/php-4.3.2/sapi/apache/sapi_apache.c:54
#9  0x282e4966 in send_php (r=0x815a034, display_source_mode=0, filename=0x0)
    at /usr/src/php/php-4.3.2/sapi/apache/mod_php4.c:617
#10 0x282e49c6 in send_parsed_php (r=0x815a034) at /usr/src/php/php-4.3.2/sapi/apache/mod_php4.c:632
#11 0x8051a0c in ap_invoke_handler ()
#12 0x80610e1 in process_request_internal ()
#13 0x8061140 in ap_process_request ()
#14 0x805a62e in child_main ()
#15 0x805a7a0 in make_child ()
#16 0x805a8bd in startup_children ()
#17 0x805adac in standalone_main ()
#18 0x805b493 in main ()
#19 0x804e289 in _start ()

regards,

Jeroen Hofstee
 [2003-06-09 23:52 UTC] sniper@php.net
When run from CLI:

#0  0x406fd0de in __select () from /lib/libc.so.6
#1  0x8563834 in __DTOR_END__ () at md4.c:255
#2  0x829bae2 in php_hostconnect (host=0x8893f74 "211.6.149.130", port=80, socktype=1, timeout=0xbfffd368)
    at /usr/src/web/php/php4/main/network.c:468

Using the timeout parameter in fsockopen() 'cures' this. :)

 [2003-09-11 01:08 UTC] iliaa@php.net
This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Apr 25 22:01:29 2024 UTC