Skip to Content.
Sympa Menu

freetds - Re: Bug in read.c

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Jon Pounder <JonP AT inline.net>
  • To: "TDS Development Group" <freetds AT franklin.metalab.unc.edu>
  • Subject: Re: Bug in read.c
  • Date: Thu, 23 May 2002 10:47:48 -0400



when I get read of 0 bytes, I usually do a select(...NULL..., timeout) to pause for a predetermined amount of time without chewing up cpu, to allow more data to arrive.

if the socket is broken, and not just out of data, check for that condition with a select and error conditions setting.


At 09:04 AM 5/23/2002 -0500, you wrote:
There appears to be an error in read.c that bit me the other day. I got a
call from the Unix police saying that my processes were eating all of the
CPU. I connected to them with gdb and found that they appeared to be stuck
in a read() loop. There had been a network outage and my programs'
connections to their db servers had been dropped, apparently precipitating
the problem. Looking at the source for goodread() in read.c it appears
that there is no allowance made for the read() call returning 0. If a
socket read, blocking or not, returns 0 it is an indication that the socket
connection has been closed/broken. This was the case in my situation.
Since read did not block and returned 0 immediately, the function looped
continuously.

It looks like you could just change line 77 of read.c from:
if (len < 0) {

to:
if (len <= 0) {

That would catch read() returning 0 and assume the socket was broken.

Opinions?

Thanks
Scott Maskell


---
You are currently subscribed to freetds as: [pounder AT inline.net]
To unsubscribe, forward this message to $subst('Email.Unsub')






Archive powered by MHonArc 2.6.24.

Top of Page