FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

I removed _db_set_null_value(), combining its little remaining logic with
dbgetnull().  Everything works.  Almost.  

30 of 33 dblib unit tests pass, all but t0011 and two new ones.  It's not
failing in a nice way, though: the code jumps into dbgetnull() when it's
*not* called.  Here's the tail of my log:

Breakpoint 2, copy_data_to_host_var (dbproc=0x804f000, srctype=47, 
    src=0x8067404 "Short column", ' ' <repeats 188 times>..., srclen=200, 
    desttype=47, dest=0xbfbfe9e0 "Short column", ' ' <repeats 188 times>, 
    destlen=-1, bindtype=1, indicator=0x0) at
../../../src/dblib/dblib.c:7032
7032            tdsdump_log(TDS_DBG_INFO1, "copy_data_to_host_var(%d [%s]
len %d => %d [%s] len %d)\n", 
(gdb) 
Continuing.
dblib.c:7032:copy_data_to_host_var(47 [SYBCHAR] len 200 => 47 [SYBCHAR]
len -1)
dblib.c:7056:copy_data_to_host_var() srctype == desttype

        Line 7056 comes *after* any possible call to dbgetnull().  
        copy_data_to_host_var() doesn't (and shouldn't) call it, 
        because src isn't NULL and srclen > 0.  

        But look what comes next:

dblib.c:513:dbgetnull(0x804f000, 1, -1, 0xbfbfe5e0)
dblib.c:542:varaddr(0xbfbfe5e0) varlen -1 < 0?

Program received signal SIGSEGV, Segmentation fault.
0x481565a6 in memset () from /usr/lib/libc.so.12
(gdb) bt
#0  0x481565a6 in memset () from /usr/lib/libc.so.12
#1  0xbfbfe5e0 in ?? ()
#2  0x48068447 in errno () from /usr/local/lib/libsybdb.so.5
#3  0x4806ab4b in dbnextrow (dbproc=0x804f000)
    at ../../../src/dblib/dblib.c:1967
#4  0x0804934b in select_rows (dbproc=0x20202020, bind_type=538976288)
    at ../../../../src/dblib/unittests/t0011.c:119
(gdb) kill

gdb can't see the stack frames.  We land in dbgetnull() -- we know so
because of the log file -- without being called in any way I can see.  And
we somehow manage to skip the test for varlen < 0, arriving at a
completely unnecessary assert.  Spooky.  I can only think the stack is
corrupted.  

Maybe it's the unit test, but nowadays I don't expect a user program to be
able to corrupt memory in db-lib.  There are too many parameter checks for
that to happen easily.  

I did remove some null pointer checks that were guarding free(3)
yesterday.  It's possible I goofed.  But I've checked over the CVS diffs
and if it's there, I don't see it.  My best hope is that the problem has
been lurking there all along and only just now surfaced.  

Perhaps someone with better tools or more energy can figure out what's
going on.  I think I've done enough damage for one night.  

--jkl