Bug 188976 - Strange hanging and CPU usage when used as a UDP client
Summary: Strange hanging and CPU usage when used as a UDP client
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: nc
Version: 5
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Radek Vokál
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-04-14 04:38 UTC by Winston Chang
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version: 1.84-5
Clone Of:
Environment:
Last Closed: 2006-07-10 07:48:01 UTC
Type: ---
Embargoed:


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

Description Winston Chang 2006-04-14 04:38:51 UTC
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 Vokál 2006-04-20 07:08:23 UTC
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 23:11:10 UTC
Created attachment 131865 [details]
Fixes endless polling by handling POLLERR event

Comment 3 Radek Vokál 2006-07-10 07:48:01 UTC
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.