FreeTDS Development Group

["Matt Kynaston" <matt AT online-canarias.com>]

Hi,

First off, I'm no C coder, so I have no idea whether this is even relevant.
But Scott's message rang some bells.

On our cheapo dev setup the hub isn't on a UPS, so when the power goes out
(frequent occurence in sunny Spain ;) the connection between the Redhat 6.2
box and SQL Server 2000 box is lost. If I've got a PHP page open that's
using a FreeTDS connection, I get script timeouts on all DB'd pages
afterwards until I restart Apache (1.3.22).

Fortunately this hasn't happened on the live servers yet (guess Verio's hubs
are on UPS ;) But I'm not looking forward to the day it does. Till now I've
been blaming PHP, but if anyone has suggestions for a fix/workaround, I'd be
glad to hear them.

FreeTDS version 0.53.

Matt

BTW, great work everyone - since the initial setup headaches, this has been
my only problem. I may lurk, but it's sincerely appreciative lurking.

> -----Original Message-----
> From: SMASKELL AT UP.COM [mailto:SMASKELL AT UP.COM]
> Sent: 23 May 2002 15:04
> Subject: Bug in read.c
>
>
> 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
>