Bug 188976 - Strange hanging and CPU usage when used as a UDP client
Strange hanging and CPU usage when used as a UDP client
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: nc (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Radek Vokal
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-04-14 00:38 EDT by Winston Chang
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version: 1.84-5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-10 03:48:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Fixes endless polling by handling POLLERR event (288 bytes, patch)
2006-07-02 19:11 EDT, Tomas Heinrich
no flags Details | Diff

  None (edit)
Description Winston Chang 2006-04-14 00:38:51 EDT
When you send a UDP datagram with nc, like so:
  echo foo | nc -u 10.0.0.123 2001
the new version of nc included with FC5 sometimes eats 100% of the CPU.

- If you send it to another listening computer (nc -l -u 2001), it returns
immediately to the command line.  This is as expected.
- If you send it to a non-listening (but existing) computer, it hangs, and nc
eats 100% of the CPU time.
- Finally, if you send it to a non-existent computer, it hangs but does not eat
CPU time.

In the tables below, I manipulated the first two variables, and the last two
variables are the results.  I ran 'nc -u -l -p 2001' to make the remote host listen.

This is nc 1.84 on FC5:

 host   host         eat
exists listen  hang  CPU
  Y      Y      N     N
  Y      N      Y     Y
  N      -      Y     N


Contrast this with nc 1.10 on an FC3 installation:

 host   host         eat
exists listen  hang  CPU
  Y      Y      N     N
  Y      N      N     N
  N      -      Y     N

In all cases, the target host was on the same subnet.  I don't know if it would
matter if the target was on a different subnet.


I personally don't understand why it should hang at all -- shouldn't it just
shoot out the UDP datagram and return?  But certainly the 100% CPU use is wrong.
Comment 1 Radek Vokal 2006-04-20 03:08:23 EDT
Well, you can always specify the timeout value with -w. But I guess the default
timeout is rather long. Will look at it. 
Comment 2 Tomas Heinrich 2006-07-02 19:11:10 EDT
Created attachment 131865 [details]
Fixes endless polling by handling POLLERR event
Comment 3 Radek Vokal 2006-07-10 03:48:01 EDT
Thanks for the patch, applied on rawhide with little change. 

Note You need to log in before you can comment on or make changes to this bug.