Skip to Content.
Sympa Menu

freetds - Re: Crash in tsql (fixed, but still has problems!)

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Varley, David(CBorn at Alcoa)" <David.Varley AT alcoa.com.au>
  • To: 'TDS Development Group' <freetds AT franklin.oit.unc.edu>
  • Subject: Re: Crash in tsql (fixed, but still has problems!)
  • Date: Mon, 12 Aug 2002 22:23:22 +0800



Brian,

That quick-fix made a huge improvement, output from tsql is looking much
closer to that from Query Analyzer. The text field now looks correct. The
differences I see are:

bit - should return 1, instead we get 1@@J or similar (1 and 3 garbage
characters)
image and varbinary - Same data, but M$ prepends 0x to the returned string
unique_identifier - doesn't look much like the M$ version

The results returned from sqsh look very similar to those from tsql before
your fix. Bit is the same, 1@@J. Image returns a whole screen full of
garbage.
Text returns similar looking garbage to that tsql used to.

I've only tested on Linux, not Tru64 yet. But as its well after midnight and
I've been staring at this screen since 7am, I'm going to have to leave
testing
for a bit now :)

David


-----Original Message-----
From: Brian Bruns [mailto:camber AT ais.org]
Sent: Monday, 12 August 2002 10:16 PM
To: TDS Development Group
Subject: [freetds] Re: Crash in tsql (fixed, but still has problems!)


tsql may just be broken wrt text columns atm. Keep in mind it's fairly
new and mostly designed as a diagnosistic tool, which is not to say we
won't fix it, just that there may be gotchas with it.

I am a bit more concerned with the problems surrounding sqsh however. Can
you describe the behaviour there? It's very possible that text columns
got broken there as well during the conversion fixes.

Background: Because of it's variability wrt to size, text column data is
not stored in the row buffer (resinfo->current_row) like normal columns
(we'd have to allocate the maxium potential size or 2 gig....obviously not
doable) but are instead stored by a per column pointer (column_textvalue).

ctlib appears to be calling with the right pointer so again info on what
sqsh is doing would be helpful.

quick fix for tsql. inside do_query add

unsigned char *src;
int srclen;

...
now above the tds_convert() call do like this:

if (is_blob_type(ctype)) {
src = (unsigned char *)col->column_textvalue;
srclen = col->column_textsize;
} else {
src = &(tds->res_info->current_row[col->column_offset]);
srclen = col->column_size;
}

and fix the call to tds_convert() to use src and srclen. I'll check in a
proper fix tonight when i get home.

Brian

> Thanks guys, that's got tsql running w/o segfault for me.
>
> Now can anyone see whats going on here ?
>
> The convert() problem on the TEXT type from the all_types
> test query still fails on sqsh and tsql. The simplified
> handling under tsql makes it easier to trace the problem,
> but I'm not too clear on how it is meant to work, I can
> just see that it isn't.
>
> Running the simply query "select _text from all_types"
> (see below for simple test)
> where _text is the 16 byte TEXT column with entry
> "20120304" as set up by the "killer query".
>
> tds_convert() gets called with a src type of 35 (SYBTEXT)
> and a dst type of 39 (SYBVARCHAR) and so calls tds_convert_text()
> to handle it, however the passed parameters to not appear to contain
> valid data.
>
> If you look at the do_query() loop in tsql, where we have
>
> col = tds->res_info->columns[i];
>
> then the correct data is actually present in col->column_textvalue
> which contains "20120304", but this doesn't seem to be passed to
> tds_convert(), instead it is passed
> &tds->res_info->current_row[col->column_offset]
> which doesn't seem to hold anything resembling the data. The conversion
> is passed on to tds_convert_text() which just malloc()s 4096 bytes
> and copies the garbage into it.
>
> This malloc()d data is returned, printed (as garbage), and then lost,
> not freed. (valgrind reports this too, 4096 bytes lost per loop).
>
> Same results under Linux and Tru64. Compiled for tds4.2, running against
> SQL Server 7.0, query works fine using M$ tools.
>
> For a minimal test case, try this:
>
> create table #text_type ( _text text )
> insert #text_type values ( '20120304' )
> select 'text' as type, _text from #text_type
> go
>
> Result should be:
> type _text
>
> text 20120304
> but we get
> type _text
> text
>
> David
>
>
> -----Original Message-----
> From: Brian Bruns [mailto:camber AT ais.org]
> Sent: Monday, 12 August 2002 2:38 AM
> To: TDS Development Group
> Subject: [freetds] Re: Crash in tsql
>
>
>
> Ok, I was on the right track, sizeof(*tds) differed between the two, I
> just didn't have time to finish it off. config.h should be included from
> tds.h (tds.h.in) otherwise we'll have this problem again in the future.
>
> Checking the fix in now.
>
> Brian
>
> On Sun, 11 Aug 2002 freddyz77 AT tin.it wrote:
>
> > > This has been the topic of discussion for the past couple of days.
For
> > > some reason tds->tds_ctx is NULL after the call to tds_connect(),
> although
> > > it is set within tds_connect(). I haven't had a chance to track it
any
> > > further.
> > >
> > > Brian
> > >
> >
> > Ok, after a bit debug (assembly level at the end) I found the problem.
> > You do not include config.h in tsql, so tds_socket appear to tsql
without
> > iconv stuff.
> >
> > Add "#include <config.h>" on top of tsql.c and it run correctly.
> > Perhaps is best to include config.h from tds.h.in ...
> >
> > freddy77
> >
>
>
> ---
> You are currently subscribed to freetds as: [David.Varley AT alcoa.com.au]
> To unsubscribe, forward this message to
> $subst('Email.Unsub')

---
You are currently subscribed to freetds as: [David.Varley AT alcoa.com.au]
To unsubscribe, forward this message to
$subst('Email.Unsub')




Archive powered by MHonArc 2.6.24.

Top of Page