FreeTDS Development Group

["Glenn, Chris" <Glenn AT addsys.com>]

Sorry if I was unclear.  I did a bit more investigation.

The new version appears to work correctly.  That is, it connects without
any error messages.  BUT, when attempting to execute any sql commands,
it core dumps.

If you notice in the log file below, the connect is reporting a failure,
but it continues on.
---------------------------------------------------
util.c:292:Starting log file for FreeTDS 0.65.dev.20061129
        on 2006-11-29 13:57:17 with debug flags 0x4fff.
iconv.c:195:names for ISO-8859-1: ISO-8859-1
iconv.c:195:names for UTF-8: UTF-8
iconv.c:195:names for UCS-2LE: UCS-2LE
iconv.c:195:names for UCS-2BE: UCS-2BE
iconv.c:361:iconv to convert client-side data to the "ANSI_X3.4-1968"
character
set
iconv.c:514:tds_iconv_info_init: converting "US-ASCII"->"UCS-2LE"
iconv.c:514:tds_iconv_info_init: converting "ISO-8859-1"->"UCS-2LE"
net.c:185:Connecting to 10.3.2.40 port 1433 (TDS version 7.0)
net.c:240:connect(2) failed: 0x73, "Operation now in progress"
net.c:242:Contents of sockaddr_in
0000 02 00 05 99 0a 03 02 28-00 00 00 00 00 00 00 00 |.......( ........|

net.c:243: sockaddr_in: sin_family = 2
                        sin_port = 9905
                        sin_addr.s_addr = 2802030a
                        (param ip_addr) = '10.3.2.40'
write.c:134:tds_put_string converting 8 bytes of "addlinux"
write.c:162:tds_put_string wrote 16 bytes
write.c:134:tds_put_string converting 2 bytes of "sa"
write.c:162:tds_put_string wrote 4 bytes
write.c:134:tds_put_string converting 4 bytes of "TSQL"
write.c:162:tds_put_string wrote 8 bytes
...
---------------------------------------------------


-----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 1:36 PM
To: FreeTDS Development Group
Subject: Re:
[freetds]IssueconnectingtoSQLServerfromLinuxHostwithnewerversionsofFreeT
DS...

> 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.
_______________________________________________
FreeTDS mailing list
FreeTDS AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds