FreeTDS Development Group

[Brian Bruns <camber AT ais.org>]

Again, my bad.  I checked in some of Bill's changes without backing out my 
local work entirely...

On Thu, 8 Aug 2002, Lowden, James K wrote:

> TDS7 logins fail with the current snapshot.  The attached patch corrects
> that.  It is just "diff -u" after applying Bill Thompson's advice (7 August,
> Bug in login.c).  
> 
> With this patch, I think the gross errors are now fixed; the current
> snapshot should work will all servers and all clients.  I would appreciate
> feedback from anyone using it, especially about problems with data
> conversion.  
> 
> I plan extensive dblib testing this weekend.  If successful, I'll put
> together another pre-release.  
> 
> --jkl
> 
> --- login.c.orig        Thu Aug  8 06:24:15 2002
> +++ login.c     Thu Aug  8 06:30:42 2002
> @@ -737,6 +737,8 @@
>     tds_put_smallint(tds, packet_size);
>     tds_put_smallint(tds, 0);
> 
> +#if 0
> +       /* cf. Bill's message of 8/7/2002 */
>     tds7_ascii2unicode(tds,config->host_name, unicode_string, 255);
>     tds_put_n(tds,unicode_string,host_name_len * 2);
>     if (!domain_login) {
> @@ -747,6 +749,22 @@
>         tds_put_n(tds,unicode_string,password_len * 2);
>     }
>     tds7_ascii2unicode(tds,config->app_name, unicode_string, 255);
> +#else
> +   tds7_ascii2unicode(tds,config->host_name, unicode_string, 255);
> +   tds_put_n(tds,unicode_string,host_name_len * 2);
> +
> +#if DOMAIN
> +   /* Do Nothing */
> +#else
> +    tds7_ascii2unicode(tds,config->user_name, unicode_string, 255);
> +    tds_put_n(tds,unicode_string,user_name_len * 2);
> +    tds7_ascii2unicode(tds,config->password, unicode_string, 255);
> +    tds7_crypt_pass(unicode_string, password_len * 2, unicode_string);
> +    tds_put_n(tds,unicode_string,password_len * 2);
> +#endif /* DOMAIN */
> +    tds7_ascii2unicode(tds,config->app_name, unicode_string, 255);
> +#endif /* Bill's code */
> +
>     tds_put_n(tds,unicode_string,app_name_len * 2);
>     tds7_ascii2unicode(tds,config->server_name, unicode_string, 255);
>     tds_put_n(tds,unicode_string,server_name_len * 2);
> 
> 
> > -----Original Message-----
> > From: Lowden, James K [mailto:LowdenJK AT bernstein.com]
> > Sent: August 6, 2002 2:19 PM
> > To: TDS Development Group
> > Subject: [freetds] segfault with TDS 7.0 login
> > 
> > 
> > All, 
> > 
> > I'm having trouble logging in with the current snapshot.  Maybe things
> > aren't set up right (I think they are) but I'm having some 
> > trouble figuring
> > out what's wrong.  
> > 
> > Environment is sqsh on NetBSD i386 to SQL Server 2000 with 
> > TDS 8.0 using the
> > Aug 6 snapshot.  
> > 
> > Segfault occurs in tds/read.c, line 351, dereferencing a null 
> > tds->in_buf.  
> > 
> > I've attached a patch to apply an assert to that pointer.  
> > I'm sure the
> > problem occurs earlier, but I don't know where to look, 
> > really.  There's a
> > malloc for it just a few lines earlier, guarded by a test against
> > tds->in_buf_max, whose very large value appears to have been 
> > initialized
> > with -1.  
> > 
> > Any suggestions?  Here's the bt:
> > 
> > (gdb) p tds->in_buf
> > $2 = (unsigned char *) 0x0
> > (gdb) p tds->in_buf_max
> > $3 = 4294967288
> > (gdb) bt 9
> > #0  tds_read_packet (tds=0x8077800) at read.c:353
> > #1  0x4808fcd3 in tds_get_byte (tds=0x8077800) at read.c:119
> > #2  0x4808be66 in tds_process_login_tokens (tds=0x8077800) at 
> > token.c:179
> > #3  0x4808ed91 in tds_connect (login=0x807a000, context=0x8076f90,
> >     parent=0x8079520) at login.c:288
> > #4  0x48088301 in ct_connect (con=0x8079520, 
> > servername=0x8076e80 "NTS0090",
> >     snamelen=2) at ct.c:302
> > #5  0x804c723 in cmd_connect (argc=1, argv=0x8078300) at 
> > cmd_connect.c:577
> > #6  0x805dcf8 in jobset_run (js=0x8076e30, cmd_line=0x8063a12 
> > "\\connect",
> >     exit_status=0xbfbfd4c4) at sqsh_job.c:487
> > #7  0x80500a1 in cmd_loop (argc=1, argv=0x8078240) at cmd_loop.c:140
> > #8  0x805dcf8 in jobset_run (js=0x8076e30,
> >     cmd_line=0x8067e7c "\\loop $script", exit_status=0xbfbfd750)
> >     at sqsh_job.c:487
> > (More stack frames follow...)
> > (gdb) l
> > 348                     /* Set the new maximum packet size */
> > 349                     tds->in_buf_max = len;
> > 350             }
> > 351
> > 352             /* Clean out the in_buf so we don't use old 
> > stuff by mistake
> > */
> > 353             assert( tds->in_buf );
> > 354             memset(tds->in_buf, 0, tds->in_buf_max);
> > 355
> > 356             /* Now get exactly how many bytes the server 
> > told us to get
> > */
> > 357             have=0;
> > 
> > Here's the patch:
> > 
> > --- read.c.orig Tue Aug  6 08:48:35 2002
> > +++ read.c      Tue Aug  6 08:35:14 2002
> > @@ -17,7 +17,9 @@
> >   * Boston, MA 02111-1307, USA.
> >   */
> > 
> > +#include <assert.h>
> >  #include <config.h>
> > +
> >  #include "tds.h"
> >  #ifdef DMALLOC
> >  #include <dmalloc.h>
> > @@ -348,6 +350,7 @@
> >         }
> > 
> >         /* Clean out the in_buf so we don't use old stuff by 
> > mistake */
> > +       assert( tds->in_buf );
> >         memset(tds->in_buf, 0, tds->in_buf_max);
> > 
> >         /* Now get exactly how many bytes the server told us to get */
> > 
> > --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.
> 
> 
> 
> ---
> You are currently subscribed to freetds as: [camber AT ais.org]
> To unsubscribe, forward this message to $subst('Email.Unsub')
> 
>