Skip to Content.
Sympa Menu

freetds - RE: segfault with TDS 7.0 login

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Brian Bruns <camber AT ais.org>
  • To: TDS Development Group <freetds AT franklin.metalab.unc.edu>
  • Subject: RE: segfault with TDS 7.0 login
  • Date: Thu, 8 Aug 2002 15:52:29 -0400 (EDT)


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')
>
>





Archive powered by MHonArc 2.6.24.

Top of Page