Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 2.4.5

Bug #10788 Net_Ping::ping() multiple calls pile up output in results buffer
Submitted: 2007-04-20 18:18 UTC
From: cconstantine Assigned: cconstantine
Status: Closed Package: Net_Ping (version 2.4.1)
PHP Version: Irrelevant OS: all
Roadmaps: 2.4.2    
Subscription  


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 : 23 - 10 = ?

 
 [2007-04-20 18:18 UTC] cconstantine (Craig Constantine)
Description: ------------ Net_Ping::ping() returns an instance of of the result class. But subsequent calls to Net_Ping::ping() leave the output from previous ping calls in the results buffer. So each result object from ping() has all previous ping output smashed in the array. We're missing a $this->_results() = array() right before ping() does it's actual work. Test script: --------------- require_once "PEAR.php"; require_once 'Net/Ping.php'; $pong = Net_Ping::factory(); // should give a successful sample of your ping's output $result = $pong->ping('www.google.com'); print_r($result); // an IP address (from a block I manage at work) which // has nothing on it, so all your ICMP echos will timeout $result = $pong->ping('209.92.3.80'); print_r($result); Expected result: ---------------- (trimmed down) I expect to find the result objects have seperate ping output, like this: [_raw_data] => Array ( [0] => PING www.l.google.com (64.233.161.147): 56 data bytes [1] => 64 bytes from 64.233.161.147: icmp_seq=0 ttl=241 time=79.640 ms [2] => 64 bytes from 64.233.161.147: icmp_seq=1 ttl=241 time=74.372 ms [3] => 64 bytes from 64.233.161.147: icmp_seq=2 ttl=241 time=80.055 ms [4] => [5] => --- www.l.google.com ping statistics --- [6] => 3 packets transmitted, 3 packets received, 0% packet loss [7] => round-trip min/avg/max/stddev = 74.372/78.022/80.055/2.587 ms ) AND [_raw_data] => Array ( [0] => PING 209.92.3.80 (209.92.3.80): 56 data bytes [1] => [2] => --- 209.92.3.80 ping statistics --- [3] => 3 packets transmitted, 0 packets received, 100% packet loss Actual result: -------------- [_raw_data] => Array ( [0] => PING www.l.google.com (64.233.161.147): 56 data bytes [1] => 64 bytes from 64.233.161.147: icmp_seq=0 ttl=241 time=79.640 ms [2] => 64 bytes from 64.233.161.147: icmp_seq=1 ttl=241 time=74.372 ms [3] => 64 bytes from 64.233.161.147: icmp_seq=2 ttl=241 time=80.055 ms [4] => [5] => --- www.l.google.com ping statistics --- [6] => 3 packets transmitted, 3 packets received, 0% packet loss [7] => round-trip min/avg/max/stddev = 74.372/78.022/80.055/2.587 ms [8] => PING 209.92.3.80 (209.92.3.80): 56 data bytes [9] => [10] => --- 209.92.3.80 ping statistics --- [11] => 3 packets transmitted, 0 packets received, 100% packet loss )

Comments

 [2007-06-05 21:21 UTC] dufuz (Helgi Þormar)
This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.