FreeTDS Development Group

["Lowden, James K" <james.k.lowden AT alliancebernstein.com>]

> From: Glenn, Chris
> Sent: Wednesday, November 29, 2006 12:00 PM
> 
> I'm not sure of the changes, but the nightly build from last night
> does NOT have the problem?  

Is that a question or a statement?  Does last night's build work for
you?

> Were there code changes that you
> anticipated would have corrected the issue?

I reorganized the code such that I find it easier to understand, to
remove certain redundant tests, and to make the error-checking logic
leave a clearer trail.  I also followed Christos's memset
recommendation.  I didn't make any change to the system calls, e.g. the
connect(2) that was giving you trouble.  

It's possible that I fixed something accidentally, although the odds run
rather longer in the opposite direction.  It's also possible that when
you added memset to your version of the code, you did it incorrectly,
failing to fix the problem, and that my new version happens to do that
correctly.  

Or it's still broken and we both don't know why....

--jkl

> -----Original Message-----
> From: freetds-bounces AT lists.ibiblio.org
> [mailto:freetds-bounces AT lists.ibiblio.org] On Behalf Of Lowden,
> James K
> Sent: Wednesday, November 29, 2006 10:47 AM
>
[freetds]IssueconnectingtoSQLServerfromLinuxHostwithnewerversionsofFreeT
> DS...
> 
> > From: ZIGLIO, Frediano, VF-IT Sent: Wednesday, November 29, 2006
> > 2:52 AM
> > 
> > > My system does not have an 'ident' command;
> > >   The system is;
> > >           Red Hat Enterprise Linux ES release 3 (Taroon
> > >           Update 8) Kernel 2.4.21-20.ELsmp on an i686
> > > 
> > > The ident tag line in the source is;
> > >   TDS_RCSID(var, "$Id: net.c,v 1.37 2005/12/05 06:01:59
> > >   freddy77 Exp $");
> > > 
> > > Chris
> > 
> > I think problem is in
> >
>
http://freetds.cvs.sourceforge.net/freetds/freetds/src/tds/net.c?r1=1.39
> > &r2=1.40 Perhaps select get a negative time for some reasons.
> 
> Chris, Thanks.  I was looking at the wrong revision.  (No ident(1)?
> 'Tis a pity.)
> 
> Freddy, Could you remind me, please, why we need tds_gettime_ms()?
> It seems to me that time(3) is good enough and very standard.
> 
> But I don't think that's the problem.  Chris is getting EINVAL from
> connect(2), before getting the time or calling select(2).  Between
> 1.39 and 1.40, no code changed before the call to connect(2).  (If
> we do keep tds_gettime_ms(), we should test the return code from
> clock_gettime(2) and, on error, call gettimeofday(2) instead, if
> available.)
> 
> Chris, my only idea right now is that you try each successive
> revision of tds_open_socket() from CVS, starting with 1.37 (just
> to make sure it works) and marching forward until it fails.  You
> can download them from SourceForge or with CVS.  Then we can see
> exactly when when it stopped working for you.  And no, I'm sorry,
> but I can't offer any anesthesia.
> 
> If Frediano proves correct and 1.40 is in fact the problematic
> revision, I'd be interested in the output of this command:
> 
> $ grep TIME  include/config.h #define HAVE_CLOCK_GETTIME 1 /* #undef
> HAVE_FUNC_LOCALTIME_R_INT */ #define HAVE_FUNC_LOCALTIME_R_TM 1 /*
> #undef HAVE_GETHRTIME */ #define HAVE_GETTIMEOFDAY 1 #define
> HAVE_SYS_TIME_H 1 #define TDS_GETTIMEMILLI_CONST CLOCK_MONOTONIC
> #define TIME_WITH_SYS_TIME 1 /* #undef TM_IN_SYS_TIME */
> 
> because preprocessor macros with 'TIME' control the behavior of
> src/tds/util.c::tds_gettime_ms().
> 
> Yours in puzzlement,
> 
> --jkl

-----------------------------------------
The information contained in this transmission may be privileged and
confidential 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 we do not 
accept
account orders and/or instructions by e-mail, and therefore will not be 
responsible
for carrying out such orders and/or instructions.  If you, as the intended 
recipient
of this message, the purpose of which is to inform and update our clients, 
prospects
and consultants of developments relating to our services and products, would 
not
like to receive further e-mail correspondence from the sender, please "reply" 
to the
sender indicating your wishes.  In the U.S.: 1345 Avenue of the Americas, New 
York,
NY 10105.