NNTPC: Failure to detect EOF when reading from a socket

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



When I checked my nntpcache server this morning, I found that an update
daemon had been running for most of the night, in a tight read() loop.
Here is a ktrace/kdump from the offending process:

 10882 nntpcached CALL  read(0x9,0x28008,0x1000)
 10882 nntpcached GIO   fd 9 read 0 bytes
       ""
 10882 nntpcached RET   read 0

(repeat ad nauseam).

I suspect the following section from Sread() in sockets.c is the problem:

      redo:
	if ((cc = read (fd, buf, len - 1)) < 1)
	{
		if (errno == EINTR)
			goto redo;
		logw (("error reading from news server"));
			return 0;
	}

Note that errno is *not* set if the read() succeeds, and that a read of 0
bytes from the network is the normal way of detecting EOF. Thus if errno
happens to be EINTR before this read() call, and the read() returns 0
bytes, we'll merrily go round and round...

I changed the code as shown below. Note that I haven't checked if the same
problem exists in other parts of the code.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no
----------------------------------------------------------------------
*** sockets.c.0	Sun Feb 16 19:31:31 1997
--- sockets.c	Mon Feb 17 10:04:48 1997
***************
*** 146,152 ****
        redo:
  	if ((cc = read (fd, buf, len - 1)) < 1)
  	{
! 		if (errno == EINTR)
  			goto redo;
  		logw (("error reading from news server"));
  			return 0;
--- 146,152 ----
        redo:
  	if ((cc = read (fd, buf, len - 1)) < 1)
  	{
! 		if (cc < 0 && errno == EINTR)
  			goto redo;
  		logw (("error reading from news server"));
  			return 0;


[Index of Archives]     [Yosemite]     [Yosemite Campsites]     [Bugtraq]     [Linux]     [Trn]

Powered by Linux