Skip to Content.
Sympa Menu

freetds - RE: [freetds] Need Help on dblib program

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Lowden, James K" <LowdenJK AT bernstein.com>
  • To: "'FreeTDS Development Group'" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] Need Help on dblib program
  • Date: Thu, 31 Jul 2003 16:11:17 -0400

> 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.






Archive powered by MHonArc 2.6.24.

Top of Page