FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: Varley, David(CBorn at Alcoa) [mailto:David.Varley AT alcoa.com.au]
> Sent: September 11, 2002 6:51 PM
> 
> I got a nice big freetds.log for you. After it crashed the
> server t0016 kept writing to the log until /tmp filespace
> ran out. (Luckily its mounted on mfs and only 10MB!)
> I truncated it, attached.

Looking at the log, it seems likely that FreeTDS kept retrying the socket
even though it was closed.  I think this is related to the cancel processing
fix.  As Brian said (paraphrasing), that's a nasty piece of work that needs
a firm hand.  But that's not what's crashing your server.  

David, is this behvior restricted to TDS 4.2 with t0016?  I wonder if it
might not be a matter of us lying to the server about the length of
something, causing it to stupidly not allocate (or over allocate) room for
the incoming row.  

I also notice that t0016.c doesn't call bcp_done() between bcp_exec() and
the next bcp_init(), nor between bcp_exec() and dbsqlexec().  That not good.
We shouldn't be able to crash the server, but nonetheless we should call
bcp_done() as appropriate.  

from the bcp_done() docs:

        Remarks

        Call bcp_done after the last call to bcp_sendrow 
        or bcp_moretext. Failure to call bcp_done after 
        copying in all your data results in unpredictable errors.  

Brian, does any of this coincide with your 12.5 experience?  

--jkl


The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above.  If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that for certain accounts we do not accept
orders and/or instructions by e-mail, and for those accounts we will not be
responsible for carrying out such orders and/or instructions. Kindly refrain
from sending orders or instructions by e-mail unless you have confirmed that
we accept such communications for your account. Please also note that to
satisfy regulatory requirements we review the outgoing and incoming e-mail
correspondence of staff members serving certain functions.