#20033 [Fbk]: Echoing/fputsing ~11k+ of data to STDOUT causes problem

From: Date: Wed, 23 Oct 2002 11:26:34 +0000
Subject: #20033 [Fbk]: Echoing/fputsing ~11k+ of data to STDOUT causes problem
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-23096@lists.php.net to get a copy of this message
ID: 20033 Updated by: msopacua@php.net Reported By: ces@vaultbbs.com Status: Feedback Bug Type: Sockets related Operating System: Red Hat 7.3 PHP Version: 4CVS-2002-10-22 New Comment: while(ftell($mailfile) < $EndOfMessagePos) This line has the potential to cause a indefinete loop and there's no escape code in the loop, which breaks it. ftell will return FALSE if an error occurs, which in numerical comparison resolves to 0. Can you change that to: while(ftell($mailfile) and ftell($mailfile) < $EndOfMessagePos) Previous Comments: ------------------------------------------------------------------------ [2002-10-23 03:54:00] wez@php.net It's more likely to be a problem with fgets; could you try fflush($logfile) ing after the fputs lines, just to make sure that they're not waiting in the buffer. Also, when php hangs, is it using a lot of CPU? ------------------------------------------------------------------------ [2002-10-22 17:42:38] ces@vaultbbs.com Code I am using is: while(ftell($mailfile) < $EndOfMessagePos) { fputs($logfile, "Getting line\n"); $line = fgets($mailfile, 4096); fputs($logfile, "Echoing line\n"); echo "$line\r\n"; $fst += strlen($line); fputs($logfile, "Sent $fst: $line\n"); } echo ".\r\n"; fputs($logfile, "Sent: CRLF\n"); fclose($logfile); End of log file returns: --START-- Getting line Echoing line Sent 11060: (unimportant email content) Getting line Echoing line Sent 11147: (unimportant email content) Getting line Echoing line --END-- Thus it appears to be hanging on the "echo" line. Again, this problem only presents itself when the script is running as a full server on a "clean" connection. If the same exact test is run connecting via the telnet command to port 110 or by running the script from the command-line there is no problem. It is my guess that the telnet command introduces some kind of flow control that is not present when I open a "real" POP3 connection to the same port. ------------------------------------------------------------------------ [2002-10-22 16:57:05] wez@php.net Can you isolate the line of code that causes the hang? Use printf to output a note before each function you suspect of causing the problem; the last line output by the script will tell you which one has hung. We need to narrow it down to either sockets (as in ext/socket), or streams (fgets, fread, fwrite etc.), or output buffer -- three unrelated areas. ------------------------------------------------------------------------ [2002-10-22 16:34:52] ces@vaultbbs.com Additional info: If I switch my binary back to php 4.1.3, my POP3 server script works 100% inasmuch as this bug is concerned. Additionally, I can confirm that something is crashing in PHP in that if I dump data to a log file, the logfile ends where the data turns to garbage. An additional log entry should be made when the message dump is complete. This is never executed. This is a weird problem that seems to cause PHP to hang, not core dump, and not terminate the TCP/IP connection but causes PHP to just dump garbage and just hang. ------------------------------------------------------------------------ [2002-10-22 16:29:48] ces@vaultbbs.com I'm writing a POP3 server daemon in PHP. Incoming requests to port 110 are routed to the POP3 server daemon by xinetd. Everything works fine if I *Telnet* to port 110. Everything also works if I just run the script from the command line. However, if I connect to my server by opening a true POP3 connection (such as from Eudora client), messages greater than about 11k cause problems when they are downloaded. I originally suspected a POP3 implementation problem on my part. However, I've confirmed that if I open a clean (non-Telnet) connection to my server and manually RETRieve the large message, the first 11k is dumped correctly but at about 11k everything else sent by PHP is garbage. It appears as though there were some kind of output buffer overflow. This also appears to damage the socket. It does NOT cause the TCP/IP connection to be terminated, but no additional output is sent and the script becomes unresponsive to additional commands sent to it. This *might* be related in some way to bug #19944 that I reported last week and which I closed this morning. This is with snap 200210220900. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=20033&edit=1

« previous php.bugs (#23096) next »