FreeTDS Development Group

["Ben Vaughn" <bvaughn AT BlackbirdTech.com>]

I have chosen to use linux (:() and OpenClient, as it doesn't give you or
I the headaches we were experiencing previously. :)

-biv

------
Ben Vaughn
Security Analyst
Blackbird Technologies
703-796-1438 W / 703-582-4551 C
bvaughn AT blackbirdtech.com
------
 

-----Original Message-----
From: Lowden, James K [mailto:LowdenJK AT bernstein.com] 
Sent: Tuesday, July 22, 2003 11:53
To: 'FreeTDS Development Group'
Subject: RE: [freetds] Crash in APACHE/PHP(compiled with sybase-ct) and
FreeTDS 0.62.dev.20030714


> From: Michael Peppler [mailto:mpeppler AT bluewin.ch]
> Sent: July 22, 2003 8:51 AM
> > 
> > I associate "bus error" with 64-bit
> > architectures.  And I don't see anything wrong with the 
> > code.  Must be something else.  
> 
> Me I associate "bus error" with data alignment errors - comes from my
> days of programming on the Sparc architecture, which is really very
> sensitive of data alignment (doubles on 8 byte boundaries, etc)
> 
> Could it be something like that here?

Quite right, I didn't express myself clearly.  It so happens that my only
experience with data alignment errors is on DEC Alpha, which of course is
64-bit.  I think of it as a "64-bit" problem because 64-bit architectures
tend to expose data alignment errors in code developed on 32-bit
platforms.
I've never seen it on I32.  

That said, here are the offending declarations and code:

typedef struct tdsnumeric
{
        unsigned char         precision;
        unsigned char         scale;
        unsigned char         array[33];
} TDS_NUMERIC;

         const TDS_NUMERIC * numeric
        const unsigned char *number;

        unsigned int packet[sizeof(numeric->array) / 2];
        unsigned int *pnum, *packet_start;
        unsigned int *const packet_end = packet + TDS_VECTOR_SIZE(packet);

        int num_bytes;
        unsigned int n;

        /* put number in a 16bit array */
        number = numeric->array;
         ^^^^^^ same type: unsigned char
        num_bytes = tds_numeric_bytes_per_prec[numeric->precision];

        n = num_bytes - 1;
             ^^^^^^^^^ should assert(num_bytes > 0);
        pnum = packet_end;
         ^^^^ same type: unsigned int

> Program received signal SIGBUS, Bus error. 
> 0x284cf2ad in tds_numeric_to_string (numeric=0x81b4564, 
> s=0xbfbfda00 ",ê\034\b") at numeric.c:279 
> 279       *--pnum = number[n - 1] * 256 + number[n]; 

I wonder if I'm looking in the wrong place, because that looks like
perfect
C to me.  "256" is an integer constant; according to K&R A2.5.1 it's of
type
int.  "number[n - 1]" is of type unsigned char; K&R A6.1 says it's
promoted
to int if possible (it's possible).  Their product is of course of type
int.
When "number[n]" is added to that, it will likewise be promoted to int.
We
wind up with *pointer-to-int = int * int + int.  I don't see an alignment
problem.  <shrug>

If either of my patches solves the problem, I'd be inclined to think we
found a compiler bug.  You?  

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


_______________________________________________
FreeTDS mailing list
FreeTDS AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds