Re: bsqldb SEGFAULT abend

"James K. Lowden" <[email protected]>
Newsgroups gmane.comp.db.tds.freetds
Message-ID <[email protected]>
Hi Ronildo, 

You found two bugs in bsqldb.  

Ronildo wrote:
> Please let me share some thoughts from the tests I've been running:
> 
> 1 - If got it right from James' first answer, we expect
> (dblib.c)+(buffering.h) to buffer_transfer_bound_data bytes limited to:
> 
>  data[c].buffer = calloc(1, metadata[c].width); 

Change that line to 

   data[c].buffer = calloc(1, 1 + metadata[c].width);  

http://freetds.cvs.sourceforge.net/viewvc/freetds/freetds/src/dblib/dblib.c?revision=1.320&view=markup&pathrev=BRANCH0_82

Your log shows:

> buffering.h:231:buffer_transfer_bound_data(0x92ad368 4040 -1 0x92ad360
> 0) dblib.c:7083:copy_data_to_host_var(35 [SYBTEXT] len 30 => 47
> [SYBCHAR] len -1)

We're copying 30 bytes and asking for a null-terminated string.  We're
promising the destination buffer is at least 36 bytes.  

Line 7143, per valgrind, memcpy(3) copies srclen bytes to dest.  That's
actually OK, because bsqldb calloc'ed 30 bytes.  But then this happens:  

	memcpy(dest, src, srclen);
	for (i = srclen; i < destlen - 1; i++)
		dest[i] = ' ';
	dest[i] = '\0';

If i == srclen, dest[i] refers to 1 byte past the end of dest.  With the
above change, we allocate width+1 bytes, so dest will be 36 bytes.  

Bug #2 is even dumber, but I don't have a proper fix yet: 
get_printable_size() doesn't handle all data types.  In particular it
doesn't handle SYBTEXT.  That's because the "size" of SYBTEXT is 2^31 or
so, which should be handled specially.  Instead it returns 0, causing
print_results() to set the width to the length of the *name* of the
column.  After which ensues a whole peck of trouble!  

If you changed your SQL to convert the column to varchar, your memory
error will go away.  I'll look to add proper SYBTEXT handling.  No reason
it can't be made to work.  

Regards, 

--jkl
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.