Re: [HACKERS] Re: Buffer overruns with the Electric Fence debugging library (Solved?)

From: "Maurice Gittens" <mgittens(at)gits(dot)nl>
To: <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] Re: Buffer overruns with the Electric Fence debugging library (Solved?)
Date: 1998-03-20 18:30:55
Message-ID: 00ba01bd542e$527881e0$fcf3b2c2@caleb..gits.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Ok,

I think I've found the problem.
The problem as I've identified it, seems to be a result of the fact that
pointers returned by palloc are not alligned in accordance with
the DOUBLEALIGN macro.

The function ComputeDataSize returns a tuple size
computed using an initial data size of 0 bytes. (which is
double aligned according to the DOUBLEALIGN macro).
This needless to say, makes sense.

However the function DataFill is called with an expression similar to:

DataFill((char *)tuple + tuple->t_hoff, ...) ;

So it happens that the address for tuple data passed to the function
DataFill,
is not double aligned in the general case.
So every now and then (when the tuple data pointer is not double aligned)
the DataFill function actually uses memory more than it should,
because the alignment macros bump the data pointer while no corresponding
space has been reserved by the function ComputeDataSize.

I think the source of the problem lies in the fact that palloc does not
return memory addresses which are double aligned.

I don't know how to solve the problem of making palloc return
MAXALIGNED addresses in a _portable_ (compiler, os, cpu ) way.

Can any one confirm this analyses and maybe give suggestions for a
portable solution?

With regards from Maurice.

Browse pgsql-hackers by date

  From Date Subject
Next Message David Gould 1998-03-20 19:15:47 Re: [HACKERS] Re: [PATCHES] patches for 6.2.1p6
Previous Message Bruce Momjian 1998-03-20 17:29:18 Re: [HACKERS] tables >2GB