FreeTDS Development Group

["Richard Norman" <normri AT samc.com>]

I did finally get it to work.  It was a weird process, but I used the 
released version of FreeTDS 0.52 and DBD::Sybase version 0.91.  After 
configuring FreeTDS, I did see some make test errors but when I installed the 
DBD, it worked fine.
 
I tried to get the unixODBC tow work with it as well.  The command line ODBC 
utilities worked and queried fine, but the Perl DBD::ODBC driver did not 
connect properly.
 
The machine was a Red Hat 6.2 Linux system, Perl 5.005(03 - not sure about 
last numbers)
 
That is a general summary of what I did to get it to work.  It took me about 
1 - 2 weeks cause I was not too familiar with Linux, but it eventually worked.
 
Hope this helps some...
 
Richard Norman

        -----Original Message-----
From: edeutsch AT systemsbiology.org 
Sent: Monday, October 22, 2001 9:34 AM
To: "TDS Development Group" <freetds AT franklin.oit.unc.edu>
Subject: [freetds] FW: RE: DBD::Sybase, FreeTDS, Solaris 2.7, Perl 5.6.1




        Hi, since things are heating up on the list again, I thought I'd 
repost an 
old message with the hope that someone can look at it.  I have not been able 
to resolve this, and it sounds like several other people are having similar 
problems.  I'd be happy to send more TDSDUMP files if that is helpful.  My 
problem occurs on with DBD::Sybase, FreeTDS 0.52 and greater, Red Hat 7.0, 
Perl 5.6.0 in contrast to the original poster's platform. 

        thanks, 
Eric 

             Original Message      
From: Eric Deutsch 
Sent: Thursday, October 04, 2001 9:56 AM 
To: TDS Development Group 
Subject: [freetds] RE: DBD::Sybase, FreeTDS, Solaris 2.7, Perl 5.6.1 



        Yes, I have had the same problem with core dumps from DBD::Sybase to 
MS SQL 
Server 2000.  The one piece of information you leave out is the TDS version 
you're using.  I bet if you revert to TDS 4.2, things will work fine.  My 
experience is that TDS 7.0 broke after FreeTDS 0.51 in a way that I cannot 
figure out.  I've attached a few relevant emails, but the summary is this: 

          the seg faults are caused by an empty login >host_name.  If you 
patch this 
problem (as shown by my message of 8/10) the seg fault goes away (but still 
other problems remain).  Mark Lilback suggested another fix (attached) which 
doesn't work for me.  But from his suggestion, if I add at the end of 
tds_config_login(): 

                if (login >host_name) { 
                config >host_name = strdup(login >server_name); 
        } 

        then the sef fault disappears.  I don't advocate this as the proper 
fix.  I 
don't understand the difference between host_name and server_name and why my 
host_name never gets set and why this causes my programs to seg fault. 
Anyway, after applying this fix, I still don't get TDS 7.0 to work. 
Instead, my programs then fail without seg faulting with: 

        Unknown marker: 0!! 

        So, I am still using a hacked version of 0.51 which is working for 
me.  I 
still cannot get the latest CVS version to work for me (in TDS 7.0; 4.2 is 
fine).  I'm also attaching my tdsdump file in the hopes that someone can 
figure out what's going on.  I'm very interested in seeing this fixed before 
release of 0.53, but I cannot figure it out.  I'm happy to assist in any way 
I can. 

        thanks, 
Eric 

        [My original message was rejected apparently because the distrib 
software 
though it was a vacation message (?!), so "attached" messages are merely 
inlined below since attachments may have been problem.] 


        >      Original Message      
> From: bounce freetds 127899 AT franklin.oit.unc.edu 
> [ mailto:bounce freetds 127899 AT franklin.oit.unc.edu]On Behalf Of Richard 
> Norman 
> Sent: Wednesday, October 03, 2001 4:28 PM 
> To: TDS Development Group 
> Subject: [freetds] RE: DBD::Sybase, FreeTDS, Solaris 2.7, Perl 5.6.1 
> 
> 
> YESS!!!! This is partly what I have been seeing as well.  I have 
> only tried FreeTDS 0.52 & 0.53 and DBD::Sybase 0.91 & 0.93.  But 
> I have also tried DBD::ODBC 0.28 / unixODBC as well. 
> 
> HELP US!!! 
> 
> : ) 
> 
> Richard Norman 
> 
>            Original Message      
> From: wrayburn AT cisco.com 
> Sent: Wednesday, October 03, 2001 4:21 PM 
> To: "TDS Development Group" <freetds AT franklin.oit.unc.edu> 
> Subject: [freetds] DBD::Sybase, FreeTDS, Solaris 2.7, Perl 5.6.1 
> 
> 
> 
>       Below are my results testing different client combinations 
> of DBD::Sybase and FreeTDS, with Solaris 2.7 and Perl 5.6.1. 
> Server is SQL Server 7, TDS is 4.2. 
> 
>       DBD::Sybase   FreeTDS    Result 
> 
> 0.22          pre 0.51   compile, run ok 
> 0.93          pre 0.51   compile, run ok 
> 
> 0.22          0.51       compile, run ok 
> 0.91          0.51       compile, run ok 
> 0.93          0.51       DBD::Sybase compile error 
> 
> 0.22          0.52       compiled, but DBD/Sybase.pm runtime error 
> 0.23          0.52       DBD::Sybase compile error 
> 0.91          0.52       compiled, but runtime core dump 
> 0.93          0.52       DBD::Sybase compile error 
> 
>       pre 0.51 refers to whatever state I grabbed out of CVS before 0.51, 
> a long time ago. 
> 
>       Have other people seen the same results using the same 
> combinations with 0.51 and 0.52? 
> 
>       Thanks, 
> Bill 
> 




        From: "Eric Deutsch" <edeutsch AT systemsbiology.org> 
Subject: [freetds] Re: CORE DUMP   Linux   TDSVER=7.0 
Date: Fri, 10 Aug 2001 11:49:55  0700 

        I recently downloaded the latest CVS version of FreeTDS in order to 
try to 
compile for Solaris, and find that it works for TDS 4.2 but not TDS 7.0, 
in fact it seg faults.  Compiling it under Linux causes the same problem, 
whereas under FreeTDS 0.51, I can successfully use either 4.2 and 7.0 on 
Linux, so it seems that TDS 7.0 broke since 0.51 (at least when accessing 
SQL Server 2000 via Perl + Sybase.pm + FreeTDS).  I know there has been 
lots of added code in this area to add features. 

        I found the problems which caused the seg faults in login.c and 
applied 
the following hacks to prevent the seg faults.  This is not a proper fix, 
but more or a hack.  I hope the principle authors of FreeTDS can figure 
out where the REAL problem lies and fix it there.  In poking around, it 
seemed a little like the pooling code already does a similar hack? so 
maybe these problems don't occur for those using pooled connections?  In 
any case, once the seg faults are prevented, the end result is: 

        Unknown marker: 0!! 

        and a graceful termination of the program.  So, this patch doesn't 
cause 
the login and query to work, but at least there's no seg fault.  I'm out 
of time for now.  Does anyone have any ideas why the above error? 

        thanks, 
Eric 


        *** login.c:orig        Sat Jul 28 08:45:45 2001 
    login.c     Fri Aug 10 11:26:32 2001 
*************** 
*** 121,128 **** 
    121,131      
  /* 13 + max string of 32bit int, 30 should cover it */ 
  char query[30]; 
+ char *host_name; /* Deutsch*/ 

          FD_ZERO (&fds); 
  /* end */ 

        +         host_name = strdup("gremlin"); 
+       tds_set_host(login,host_name); 
        config = tds_get_config(tds, login); 

        *************** 
*** 226,230 **** 
        /* get_incoming(tds >s);  */ 
        if (!tds_process_login_tokens(tds)) { 
!               tds_free_config(config); 
                tds_free_socket(tds); 
                tds = NULL; 
    229,233      
        /* get_incoming(tds >s);  */ 
        if (!tds_process_login_tokens(tds)) { 
!               /*tds_free_config(config);*/ 
                tds_free_socket(tds); 
                tds = NULL; 


        commentary: first seg fault is caused because config >host_name never 
gets set, so when strlen() or any other function is called on it, seg 
fault occurs.  Where should login >host_name (and thus config >host_name 
get originally set?).  The second seg fault occurs when the login fails 
and the tds_free_config() can be called twice, the second time causing a 
seg fault.  I commented out the above tds_free_config() because it appears 
to be guaranteed that it will be called again a few lines later.  An 
alternate fix might be to "return NULL" at the end of this if block.. 




        On Fri, 10 Aug 2001, Lance wrote: 

        > 
>  I am receiving a core dump. 
> 
>  In my freetds.conf file the tds version = 7.0 (both global section 
>  and the section specific to my connection). The ms sql server is 
>  7.0. I am using redhat with kernel 2.4.3. 
> 
>  I am testing using the unittests in the dblib directory and get the dump. 
> 
>  I can test the unittests in the tds directory without any problem! 
> 
>  It also seg faults (core dumps) when I try to connect via PHP. 
> 
>  I have tried both the .52 tarball and the latest CVS with the same 
results. 
> 
>  HELP!!!! 
> 
> Lance 
> 



        From: "Mark J. Lilback" <mark AT lilback.com> 
Subject: [freetds] Re: CORE DUMP   Linux   TDSVER=7.0 
Date: Fri, 10 Aug 2001 17:08:59  0700 

        >and a graceful termination of the program.  So, this patch doesn't 
cause 
>the login and query to work, but at least there's no seg fault.  I'm out 
>of time for now.  Does anyone have any ideas why the above error? 

        I was getting serious crashes at login the last time I synched my 
code with cvs. I added the following to the end of tds_config_login 
in config.c: 

                        if (login >host_name) { 
                config >ip_addr = calloc(sizeof(char)*16,1); 
                lookup_host(login >host_name, NULL, config >ip_addr, NULL); 
        } 

        If you're using config files or environment variables, the cvs code 
works fine. Otherwise, you need the host to be resolved and copied 
from the TDSLOGIN struct to the config struct. 


           
__________________________________________________________________________ 
                                          "The best assumption to have 
Mark J. Lilback                           is that any commonly held 
<mark AT lilback.com>                        belief is wrong."    Ken Olsen, 
http://www.lilback.com/                   founder, Digital Equip. Corp. 



        tdsdump.log: 

        2001 10 03 19:15:56 Connecting addr 10.0.0.234 port 1433 
Sending packet @ 2001 10 03 19:15:56 
0000  10 01 01 04 00 00 01 00 fc 00 00 00 00 00 00 80   |........u.......| 
0010  00 00 00 00 00 00 00 06 83 f2 f8 ff 00 00 00 00   |.........ooy....| 
0020  e0 03 00 00 88 ff ff ff 36 04 00 00 56 00 09 00   |a....yyy6...V...| 
0030  68 00 05 00 72 00 05 00 7c 00 0b 00 92 00 09 00   |h...r...|.......| 
0040  00 00 00 00 a4 00 0a 00 b8 00 0a 00 cc 00 00 00   |....$...,...I...| 
0050  00 40 33 9a 6b 50 cc 00 30 00 fc 00 00 00 49 00   |.@3.kPI.0.u...I.| 
0060  53 00 42 00 53 00 65 00 72 00 76 00 65 00 72 00   |S.B.S.e.r.v.e.r.| 
0070  67 00 75 00 65 00 73 00 74 00 d3 a5 f2 a5 f3 a5   |g.u.e.s.t.OYoYoY| 
0080  92 a5 e2 a5 7a 00 7a 00 73 00 69 00 6d 00 70 00   |.YaYz.z.s.i.m.p.| 
0090  6c 00 65 00 2e 00 70 00 6c 00 49 00 53 00 42 00   |l.e...p.l.I.S.B.| 
00a0  53 00 65 00 72 00 76 00 65 00 72 00 43 00 54 00   |S.e.r.v.e.r.C.T.| 
00b0  2d 00 4c 00 69 00 62 00 72 00 61 00 72 00 79 00   | .L.i.b.r.a.r.y.| 
00c0  75 00 73 00 5f 00 65 00 6e 00 67 00 6c 00 69 00   |u.s._.e.n.g.l.i.| 
00d0  73 00 68 00 4e 54 4c 4d 53 53 50 00 01 00 00 00   |s.h.NTLMSSP.....| 
00e0  06 82 00 00 00 00 00 00 00 00 00 00 00 00 00 00   |................| 
00f0  00 00 00 00 00 00 00 00 30 00 00 00 00 00 00 00   |........0.......| 
0100  30 00 00 00                                       |0...| 


        2001 10 03 19:15:56 inside tds_process_login_tokens() 
Received packet @ 2001 10 03 19:15:56 
0000  e3 1b 00 01 06 74 00 65 00 73 00 74 00 64 00 62   |a....t.e.s.t.d.b| 
0010  00 06 6d 00 61 00 73 00 74 00 65 00 72 00 ab 64   |..m.a.s.t.e.r.<d| 
0020  00 45 16 00 00 02 00 25 00 43 00 68 00 61 00 6e   |.E.....%.C.h.a.n| 
0030  00 67 00 65 00 64 00 20 00 64 00 61 00 74 00 61   |.g.e.d. .d.a.t.a| 
0040  00 62 00 61 00 73 00 65 00 20 00 63 00 6f 00 6e   |.b.a.s.e. .c.o.n| 
0050  00 74 00 65 00 78 00 74 00 20 00 74 00 6f 00 20   |.t.e.x.t. .t.o. | 
0060  00 27 00 74 00 65 00 73 00 74 00 64 00 62 00 27   |.'.t.e.s.t.d.b.'| 
0070  00 2e 00 07 4d 00 53 00 53 00 51 00 4c 00 30 00   |....M.S.S.Q.L.0.| 
0080  31 00 00 00 00 e3 08 00 07 05 09 04 d0 00 34 00   |1....a......D.4.| 
0090  e3 17 00 02 0a 75 00 73 00 5f 00 65 00 6e 00 67   |a....u.s._.e.n.g| 
00a0  00 6c 00 69 00 73 00 68 00 00 ab 68 00 47 16 00   |.l.i.s.h..<h.G..| 
00b0  00 01 00 27 00 43 00 68 00 61 00 6e 00 67 00 65   |...'.C.h.a.n.g.e| 
00c0  00 64 00 20 00 6c 00 61 00 6e 00 67 00 75 00 61   |.d. .l.a.n.g.u.a| 
00d0  00 67 00 65 00 20 00 73 00 65 00 74 00 74 00 69   |.g.e. .s.e.t.t.i| 
00e0  00 6e 00 67 00 20 00 74 00 6f 00 20 00 75 00 73   |.n.g. .t.o. .u.s| 
00f0  00 5f 00 65 00 6e 00 67 00 6c 00 69 00 73 00 68   |._.e.n.g.l.i.s.h| 
0100  00 2e 00 07 4d 00 53 00 53 00 51 00 4c 00 30 00   |....M.S.S.Q.L.0.| 
0110  31 00 00 00 00 ad 36 00 01 07 01 00 00 16 4d 00   |1.... 6.......M.| 
0120  69 00 63 00 72 00 6f 00 73 00 6f 00 66 00 74 00   |i.c.r.o.s.o.f.t.| 
0130  20 00 53 00 51 00 4c 00 20 00 53 00 65 00 72 00   | .S.Q.L. .S.e.r.| 
0140  76 00 65 00 72 00 00 00 00 00 08 00 00 c2 e3 13   |v.e.r........Aa.| 
0150  00 04 04 34 00 30 00 39 00 36 00 04 34 00 30 00   |...4.0.9.6..4.0.| 
0160  39 00 36 00 fd 00 00 00 00 00 00 00 00            |9.6.y........| 


        2001 10 03 19:15:56 inside tds_process_default_tokens() marker is e3 
2001 10 03 19:15:56 inside tds_process_default_tokens() marker is ab 
2001 10 03 19:15:56 Msg 5701, Level 0, State 2, Server MSSQL01, Line 0 
Changed database context to 'testdb'. 
2001 10 03 19:15:56 inside tds_process_default_tokens() marker is e3 
2001 10 03 19:15:56 inside tds_process_default_tokens() marker is 0 
2001 10 03 19:15:56 leaving ct_connect() returning 0 




            
You are currently subscribed to freetds as: [normri AT samc.com] 
To unsubscribe, forward this message to leave freetds 
137192W AT franklin.oit.unc.edu