FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: Steven J. Backus [mailto:backus AT math.utah.edu]
> Sent: July 30, 2003 5:44 PM
> 
> Thanks James, here's what happened:
> 
> Hardware watchpoint 2: *(DBCHAR *) 134510167
> 
> Old value = 0 '\000'
> New value = 84 'T'
> 0xdfb6cfce in memcpy () from /usr/lib/libc.so.1
> (gdb) bt
> #0  0xdfb6cfce in memcpy () from /usr/lib/libc.so.1
> #1  0x4 in ?? ()
> #2  0x804a471 in buffer_transfer_bound_data (rowtype=-1, 
>     compute_id=-542220138, buf=0x807b914, dbproc=0x807b910, row_num=1)
>     at dblib.c:449
> #3  0x804b594 in dbnextrow (dbproc=0x807b910) at dblib.c:1542
> #4  0x804cf9d in dbprrow (dbproc=0x807b910) at dblib.c:2836
> #5  0x8049b75 in main (argc=1, argv=0x80476ac) at test_prog.c:64

Hi Steve, 

OK, that's progress of a kind, eh?  Thanks for going to the effort.  

Line 449 is a call to dbconvert(), which unsurprisingly has many calls to
memcpy().  Most of them don't matter to us, however, because we should be
able to narrow down what's going on by looking at your log.  

One of two things is true, if indeed dbconvert() is the culprit: the
corruption happens either during or after the conversion of i5 to char.  I
guess "during"; your TDSDUMP log will say for sure.  When you hit the
watchpoint, it should show something like this (I've replaced the time with
the relevant column names):

tds_get_char_data: reading 1 on wire for 0 to client
id      dbconvert() srctype = 56 desttype = 56
        dbconvert() srctype == desttype
did     dbconvert() srctype = 56 desttype = 56
        dbconvert() srctype == desttype
dmonth  dbconvert() srctype = 56 desttype = 56
        dbconvert() srctype == desttype
dday    dbconvert() srctype = 56 desttype = 56
        dbconvert() srctype == desttype
dyear   dbconvert() srctype = 56 desttype = 56
        dbconvert() srctype == desttype
dage    dbconvert() srctype = 62 desttype = 59
        dbconvert() calling tds_convert
        dbconvert() called tds_convert returned 4
orderinlist     dbconvert() srctype = 56 desttype = 56
        dbconvert() srctype == desttype
        ... nulls ...
i5      dbconvert() srctype = 39 desttype = 47
        dbconvert() calling tds_convert
        dbconvert() called tds_convert returned 3
                                    important ^^^
        dbconvert() outputting 3 bytes character data destlen = -2
family  dbconvert() srctype = 39 desttype = 47
        dbconvert() calling tds_convert
        dbconvert() called tds_convert returned 1
        dbconvert() outputting 1 bytes character data destlen = -1
        leaving dbnextrow() returning -1
        dbnextrow()
        processing row tokens.  marker is  fd(DONE)

What does your log show?  Does it stop just before the "family" conversion?


Toward the end of src/dblib/dblib.c::dbconvert(), you'll see a long switch
on desttype.  See the memcpy() on line 1905.  That's the one that pulls the
"converted" 3 bytes ('I64') out of the output buffer allocated by
tds_convert().  

If tds_convert() isn't returning 3 for you, we have to find out why,
starting with looking carefully at its inputs.  If it is, we should look
closely at its output structure (a union).  It might be worthwhile to print
out all the union's members.  

I hope there's nothing deeper wrong, but I fear there might be.  Tell me if
I'm in the right ballpark, and we'll see what else we can think of.   

Regards, 

--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 we do not accept account orders and/or instructions 
by e-mail, and therefore will not be responsible for carrying out such orders 
and/or instructions.