Skip to Content.
Sympa Menu

freetds - [freetds] how to corrupt a table

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT freetds.org>
  • To: TDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: [freetds] how to corrupt a table
  • Date: Thu, 29 Nov 2007 00:02:29 -0500

I'm always surprised when I can corrupt a table at will. I'm not quite
sure of the details yet, but something in our bcp for TDS 5.0 is currently
able to load data into a table that can't be selected back out.

After loading the table with my test program, neither sqsh nor Sybase's
isql can select the row. The TDSDUMP and tcpdump records agree, and
Sybase's Ribo tool also cannot decode the stream.

1> select * from T
2> go
t r s
----------- -------------------- ------------------------------
1 1.100000 one
2 2.200000 two
NULL 3.300000 three
4 4.400000 four
0 5.500000 five
6 2.075256
Open Client Message
Layer 0, Origin 0, Severity 78, Number 52
Unknown marker

And here's the last bit of the packet:

-- the "five" row
d1
04 00 00 00 00
04 00 00 b0 40
04 66 69 76 65

-- the "six" row
d1
04 06 00 00 00
03 00 d1 04
07 00 00 00 04 66 66 f6

40 01 30 ????
^^ FreeTDS reports 0x40 as the "unknown marker"

-- the "eight" row
d1
04 08 00 00 00
04 cd cc 0c 41
05 65 69 67 68 74

fd 10 00 02 00 08 00 00 00

The problem appears to be that the "six" and "seven" rows are actually
missing some bytes:

-- the "six" row
d1
04 06 00 00 00
03 00
-- oops!

d1
04 07 00 00 00
04 66 66 f6 40
01 30
-- more oops: the data should be 'seven'

Here's a clue:

[25] alex.FreeTDS.1> sp_layout T
[25] alex.FreeTDS.2> go
ColumnName Type Length Nulls
---------- ------------------------- ----------- -----
t int 4 Y
r real 4 Y
s varchar 30 N
^^^ not NULL!


1> select t, coalesce(s, "s can't be null") from T where t = 6
2> go
t
----------- ------------------------------
6 s can't be null

Apparently, we can load a NULL into a non-NULL column. There's logic in
bcp.c to prevent that, and you'd think think the server would object! But
it doesn't, and there's no appropriate message in master..sysmessages, so
it looks like it's the client's obligation to get right.

Back to the rockpile.

--jkl




Archive powered by MHonArc 2.6.24.

Top of Page