FreeTDS Development Group

[Frediano Ziglio <freddy77 AT gmail.com>]

2016-03-24 21:02 GMT+00:00 Mike Jetzer <mjetzer.cdc AT gmail.com>:
> I had this issue when I first put up freetds-0.95.80 a couple of months
> ago, and the problem persists in 0.95.88.
>
> Compiled under HP-UX B.11.31 using the "cc: HP C/aC++ B3910B A.06.20 [May
> 13 2008]" compiler in 32-bit mode.  I initially compiled with "-O", but the
> problem persists when compiling with "-g".
>
> Relevant freetds.conf info; this refers to an SQL Server database:
>         [testconn]
>                 host           = mkenday
>                 port           = 1433
>                 client charset = UTF-8
>                 tds version    = 7.3
>
> Here's the table I'm using in my feasibility study:
>         create table item
>         (
>         itm_num       nvarchar(40)  not null default '',
>         itm_desc      nvarchar(33)  not null default '',
>         shelf_life    integer       not null default 0,
>         itm_wid       decimal (9,2) not null default 0.0,
>         last_cc_dt_tm datetime2(3)  not null default '1980-01-01 00:00:00'
>         )
>
> And the one row of data I'm using:
>         insert into item ( itm_num, shelf_life, itm_wid, last_cc_dt_tm )
>         values ( 'ITM_NUM 12345', 1, 2.3, '2016-01-02 03:04:05')
>
> FreeTDS cores when attempting to do a "select * from item", either using
> tsql or the isql from unixODBC-2.3.4.  If I select only certain fields, it
> may succeed, but if I "select *" or the wrong combination of fields, it
> dumps core (the problem appears to be with the datetime2 field).
>
> Running the tsql from 0.95.88 in gdb:
>         $ gdb -q tsql
>         (gdb) run -S testconn -U osb3prog1 -P osb3prog1
>         Starting program: /u1/sqlprog/freetds-0.95.88/src/apps/tsql -S
> testconn -U osb3prog1 -P osb3prog1
>         locale is "en_US.utf8 en_US.utf8 en_US.utf8 en_US.utf8 C en_US.utf8"
>         locale charset is "utf8"
>         using default charset "UTF-8"
>         [New process 2721]
>         warning: reading register 584: No such process
>         Detaching after fork from process 2721
>         1> select * from item
>         2> go
>         itm_num itm_desc        shelf_life      itm_wid last_cc_dt_tm
>
>         Program received signal SIGBUS, Bus error
>           si_code: 1 - BUS_ADRALN - Invalid address alignment. Please refer
> to the following link that helps in handling unaligned data:
> http://docs.hp.com/en/7730/newhelp0610/pragmas.htm#pragma-pack-ex3.
>         0x4096760:1 in tds_msdatetime_get (tds=0x4002b440, col=0x4005d890)
>             at data.c:1110
>         1110                    dt->time = u8;
>         (gdb) p dt
>         $1 = (struct {...} *) 0x40060ffc
>         (gdb) p *dt
>         $2 = {time = 0, date = 0, offset = 0, time_prec = 3, _res = 0,
> has_time = 0,
>           has_date = 0, has_offset = 0}
>         (gdb) p &dt->time
>         $3 = (unsigned long long *) 0x40060ffc
>         (gdb) where
>         #0  0x4096760:1 in tds_msdatetime_get (tds=0x4002b440,
> col=0x4005d890)
>             at data.c:1110
>         #1  0x403c830:0 in tds_process_row (tds=0x4002b440) at token.c:1954
>         #2  0x403fd00:0 in tds_process_tokens (tds=0x4002b440,
> result_type=0x7fff7cb0,
>             done_flags=0x0, flag=5384) at token.c:685
>         #3  0x4026c60:0 in do_query (tds=0x4002b440,
>             buf=0x4005a1d0 "select * from item\n", opt_flags=0) at
> tsql.c:233
>         #4  0x402c1d0:0 in main (argc=7, argv=0x7fff8380) at tsql.c:872
>
> The URL to which gdb refers is no longer valid and HP doesn't have a
> redirect for it, but refers to pragmas for aligning structures.  However,
> dt is a pointer into the column_data field of a variable of type TDSCOLUMN,
> which is just an "unsigned char *", so from my cursory reading of the
> pragmas, this wouldn't help.  Additionally, there's a possibility that I'll
> also need FreeTDS under Solaris, AIX, and Linux; as FreeTDS is OpenSource I
> assume it'll work under Linux but am worried that the same issue might crop
> up under Solaris and AIX.

This came quite surprisingly. Probably 64 bit and Intel machines do
not help to detect these issues.
Fixed in git (both master and 0.95), expect a new snapshot tomorrow.

Frediano