FreeTDS Development Group

["Eric Deutsch" <edeutsch AT systemsbiology.org>]

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 fails 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