Skip to Content.
Sympa Menu

freetds - RE: [freetds] HP/UX and iconv

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] HP/UX and iconv
  • Date: Fri, 12 Dec 2003 14:43:33 -0500

> From: Marquess, Dustin [mailto:Dustin.Marquess AT allegiancetelecom.com]
> Sent: December 12, 2003 1:45 PM
>
> Sounds like some code that is not 64-bit clean. If you
> compile FreeTDS with
> the cc compiler with the -taso -xtaso options, it will
> probably work around
> these problems.
>
> You should be able to run gdb or ladebug against those memory
> locations to
> find the culprit.

Thanks, Dustin. You're absolutely right. I just read uac(1); I haven't
found the gcc switch, if it exists, to align things.

Here's an example. In write.c::tds_put_string:

tds_put_string(TDSSOCKET * tds, const char *s, int len)
{
TDS_ENCODING *client, *server;
char outbuf[256], *poutbuf;
unsigned int inbytesleft, outbytesleft, bytes_out = 0;
[...]
if (-1 == tds_iconv(tds, tds->iconv_info[client2ucs2], to_server,
&s, &inbytesleft, &poutbuf, &outbytesleft))


We take the address of outbytesleft. Because it's declared behind an int,
it's on a 4-byte boundary. Inside the iconv() function (our replacement),
there's this line:

copybytes = (*inbytesleft < *outbytesleft)? *inbytesleft :
*outbytesleft;

which generates a fixup message, see below. What to do?

I guess I think the compiler should see that I'm taking the address of a
variable, and ensure that variable is 64-bit aligned. I'm further guessing
that gcc 3.3 doesn't do that, at least not automatically.

I can't believe that in 2003 we're still expected to even *think* about
variable declaration order. There has to be a better answer. If free
software is going to change the world, it won't be 4 bytes at a time.

--jkl

gdb session:

Breakpoint 3, iconv (cd=0x80, inbuf=0x0, inbytesleft=0x140014300,
outbuf=0x11fffe650, outbytesleft=0x11fffe644)
at ../../../src/replacements/iconv.c:149
149 assert(inbuf && inbytesleft && outbuf && outbytesleft);
(gdb) n
143 {
(gdb)
149 assert(inbuf && inbytesleft && outbuf && outbytesleft);
(gdb)
143 {
(gdb)
146 int finvalid = 0;
(gdb)
149 assert(inbuf && inbytesleft && outbuf && outbytesleft);
(gdb)
151 copybytes = (*inbytesleft < *outbytesleft)? *inbytesleft :
*outbytesleft;
(gdb)
Unaligned access pid=11137 <t0001> va=0x11fffe644 pc=0x3ffbfff0140
ra=0x3ffbffeb89c inst=0xa4ac0000
153 switch ((int)cd) {
(gdb)
151 copybytes = (*inbytesleft < *outbytesleft)? *inbytesleft :
*outbytesleft;
(gdb) p inbytesleft
$2 = (size_t *) 0x11fffe640
(gdb) p outbytesleft
$3 = (size_t *) 0x11fffe644
(gdb) p sizeof(void*)
$4 = 8
(gdb) p 0x11fffe644 % 8
$5 = 4
(gdb) p 0x11fffe640 % 8
$6 = 0
(gdb) bt 5
#0 iconv (cd=0x2, inbuf=0x11fffe648, inbytesleft=0x11fffe640,
outbuf=0x11fffe650, outbytesleft=0x11fffe644)
at ../../../src/replacements/iconv.c:151
#1 0x3ffbffeb89c in tds_iconv (tds=0x140014300, iconv_info=0x140004a00,
io=to_server, inbuf=0x11fffe648, inbytesleft=0x11fffe640,
outbuf=0x11fffe650, outbytesleft=0x11fffe644)
at ../../../src/tds/iconv.c:695
#2 0x3ffbffda370 in tds_put_string (tds=0x140014300,
s=0x1400031c0 "dec050.beehive.com", len=0) at
../../../src/tds/write.c:159
#3 0x3ffbffd8c4c in tds7_send_login (tds=0x140014300,
connect_info=0x140003200) at ../../../src/tds/login.c:851
#4 0x3ffbffd7660 in tds_connect (tds=0x140014300, connect_info=0x140003200)
at ../../../src/tds/login.c:372
[end session]
-----------------------------------------
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