Re: bsqldb SEGFAULT abend
"Ronildo" <[email protected]>
| Newsgroups | gmane.comp.db.tds.freetds |
|---|---|
| Message-ID | <[email protected]> |
Hi James, Thanks for your help. I made the change to allocate width+1 bytes for the destination buffer, and asked SQL Server to CAST(CMD_LINE AS VARCHAR). Tests run fine without any errors both under MALLOC_CHECK_ and valgrind. For the time being those changes will suffice. Hope you guys have the opportunity to implement SYBTEXT proper handling in the near future. Best Regards, Ronildo -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of James K. Lowden Sent: quinta-feira, 1 de abril de 2010 21:26 To: FreeTDS Development Group Subject: Re: [freetds] bsqldb SEGFAULT abend 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 _______________________________________________ FreeTDS mailing list [email protected] http://lists.ibiblio.org/mailman/listinfo/freetds