Skip to Content.
Sympa Menu

freetds - RE: [freetds] Crash in APACHE/PHP(compiled with sybase-ct) and Fr eeTDS 0.62.dev.20030714

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] Crash in APACHE/PHP(compiled with sybase-ct) and Fr eeTDS 0.62.dev.20030714
  • Date: Tue, 22 Jul 2003 11:53:01 -0400

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






Archive powered by MHonArc 2.6.24.

Top of Page