php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #22099 Strange freeze when EOF reached in socket.
Submitted: 2003-02-06 17:17 UTC Modified: 2003-02-15 09:14 UTC
From: sthomas at townnews dot com Assigned: wez (profile)
Status: Closed Package: Sockets related
PHP Version: 4.3.1-dev OS: Redhat 7.3
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: sthomas at townnews dot com
New email:
PHP Version: OS:

 

 [2003-02-06 17:17 UTC] sthomas at townnews dot com
I'm not sure this bug is related to bug #21529 or not; this is not a segfault, but a simple program hang.  This is from a script I run from a PHP CLI, and is intermittent.  I'd attach the script, but it's a 10k class file...  I've used stream_set_timeout to set the limit to two seconds, and the connect timeout is also two seconds.  From my debugging output, there are no infinite loops, the freezes are essentially random, and sometimes nonexistent - but always before a single call to fclose after feof() returns true.  This leads me to believe that a remote server I'm contacting isn't behaving properly 100% of the time

php -m returns:

[PHP Modules]
ctype
dio
ftp
mysql
overload
pcre
pgsql
posix
session
standard
tokenizer
wddx
xml
zlib

Backtrace:

#0  0x401c941e in select () from /lib/libc.so.6
#1  0x08199f44 in __DTOR_END__ ()
#2  0x08121d01 in _php_stream_free (stream=0x83079c4, close_options=3)
    at /home/install/php-4.3.0/main/streams.c:327
#3  0x080acff7 in zif_fclose (ht=1, return_value=0x825e32c, this_ptr=0x0, 
    return_value_used=0) at /home/install/php-4.3.0/ext/standard/file.c:1120
#4  0x0815b05c in execute (op_array=0x823a26c)
    at /home/install/php-4.3.0/Zend/zend_execute.c:1596
#5  0x0815b234 in execute (op_array=0x822b5f0)
    at /home/install/php-4.3.0/Zend/zend_execute.c:1640
#6  0x0815b234 in execute (op_array=0x8222518)
    at /home/install/php-4.3.0/Zend/zend_execute.c:1640
#7  0x0815b234 in execute (op_array=0x81daaa4)
    at /home/install/php-4.3.0/Zend/zend_execute.c:1640
#8  0x08145398 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at /home/install/php-4.3.0/Zend/zend.c:864
#9  0x081188b5 in php_execute_script (primary_file=0xbffffa40)
    at /home/install/php-4.3.0/main/main.c:1573
#10 0x08163ecc in main (argc=2, argv=0xbffffae4)
    at /home/install/php-4.3.0/sapi/cli/php_cli.c:746
#11 0x4010a1c4 in __libc_start_main () from /lib/libc.so.6

I did it three times to make sure, and aside from memory segments, the trace is the same.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-02-06 17:37 UTC] sniper@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip


..and you'll know for sure if it's related to #21529 since
that was fixed in CVS..

 [2003-02-06 18:56 UTC] sthomas at townnews dot com
Nope, problem still exists.  As of right now, it's hanging on a piece of code that looks like this:

------------ CODE ------------

print "Unresponsive server, closing connection... ";
ob_flush();

if (is_resource($this->m_rConn))
  fclose($this->m_rConn);

$this->m_rConn = NULL;
print "Done!\n";
ob_flush();

------------ CODE ------------

Note that it's not printing "Done!" in the spot where it is freezing.  Meaning it's either is_resource, or fclose.  How's that for nasty?
 [2003-02-07 06:30 UTC] sniper@php.net
Would it be possible to give us some complete (but short!) 
example script that we can use to test this ourselves? 

You've got some objects mixed there and I guess you're
also using some output buffering too?

If possible, try creating a script that only has the socket
stuff in it, without the ob_* and OO.


 [2003-02-07 09:11 UTC] sthomas at townnews dot com
Well, originally I had the ob_flush in there because flush and ob_implicit_flush didn't work, but that seems to be fixed now.  Making this test script was *not* easy; tracking this bug down has been driving me nuts.  If you want my list of hosts, you're welcome to it, but it froze on mail.uu.net last time I ran it.  Here you go:

<?PHP

// Turn on flushing so we can see debug output.

ob_implicit_flush(1);

// hosts.txt is a file of about 170 hosts I'm sending mail
// to with my SMTP class.  Don't worry, I'm not a spammer,
// we run a home-grown mailing list software our newspapers
// use - strictly subscription based.

$aHosts = file('hosts.txt');

foreach ($aHosts as $sDomain)
{
  $sDomain = rtrim($sDomain);

  print "Testing $sDomain...\n";

  $aMX = array();

  // Obviously I skip hosts with no MX records.

  if (!getmxrr($sDomain, $aMX))
    continue;

  foreach ($aMX as $sMXHost)
  {
    print "Connecting to $sMXHost...\n";

    $nError = $sError = NULL;
    $rSock = fsockopen($sMXHost, 25, $nError, $sError, 2);

    if (!is_resource($rSock))
    {
      print "Error '$sError' skipping.\n";
      continue;
    }
    stream_set_timeout($rSock, 2);

    // Now we read to EOF, since that seems to be where
    // the problem is.  I'm also putting in a PHP timeout
    // to make sure the while loop ends.

    $nTimeout = time() + 3;

    while (is_resource($rSock) && !feof($rSock) &&
           time() < $nTimeout)
    {
      print fgets($rSock, 1024);
    }

    // And here's the issue.  Eventually the script will just
    // freeze, before it gets to the last print statement.

    print "Closing connection...";
    if (is_resource($rSock))
      fclose($rSock);
    print "Done!\n";
  }
}

?>

And here's a new backtrace for the php4-STABLE tarball I downloaded last night.

#0  0x401c941e in select () from /lib/libc.so.6
#1  0x08199a44 in __DTOR_END__ ()
#2  0x08122165 in _php_stream_free (stream=0x81eb54c, close_options=3)
    at /home/install/php4-STABLE-200302062230/main/streams.c:327
#3  0x080ad01f in zif_fclose (ht=1, return_value=0x81e7c2c, this_ptr=0x0, 
    return_value_used=0)
    at /home/install/php4-STABLE-200302062230/ext/standard/file.c:1120
#4  0x0815b2d0 in execute (op_array=0x81d8c44)
    at /home/install/php4-STABLE-200302062230/Zend/zend_execute.c:1596
#5  0x0814560c in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at /home/install/php4-STABLE-200302062230/Zend/zend.c:864
#6  0x08118b39 in php_execute_script (primary_file=0xbffffa50)
    at /home/install/php4-STABLE-200302062230/main/main.c:1582
#7  0x08164180 in main (argc=2, argv=0xbffffaf4)
    at /home/install/php4-STABLE-200302062230/sapi/cli/php_cli.c:753
#8  0x4010a1c4 in __libc_start_main () from /lib/libc.so.6
 [2003-02-13 08:23 UTC] wez@php.net
Duplicate of #21809.
 [2003-02-15 09:14 UTC] wez@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 Nov 21 20:01:29 2024 UTC