Re: mcvstats serialization code is still shy of a load - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: mcvstats serialization code is still shy of a load
Date
Msg-id 20190626074946.r5rcdhm4ucn4ivhm@development
Whole thread Raw
In response to mcvstats serialization code is still shy of a load  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: mcvstats serialization code is still shy of a load
Re: mcvstats serialization code is still shy of a load
List pgsql-hackers
On Tue, Jun 25, 2019 at 11:52:28PM -0400, Tom Lane wrote:
>I'm seeing a reproducible bus error here:
>
>#0  0x00417420 in statext_mcv_serialize (mcvlist=0x62223450, stats=Variable "stats" is not available.
>)
>    at mcv.c:785
>785                     memcpy(ITEM_BASE_FREQUENCY(item, ndims), &mcvitem->base_frequency, sizeof(double));
>
>What appears to be happening is that since ITEM_BASE_FREQUENCY is defined as
>
>#define ITEM_BASE_FREQUENCY(item,ndims)    ((double *) (ITEM_FREQUENCY(item, ndims) + 1))
>
>the compiler is assuming that the first argument to memcpy is
>double-aligned, and it is generating code that depends on that being
>true, and of course it isn't true and kaboom.
>
>You can *not* cast something to an aligned pointer type if it's not
>actually certain to be aligned suitably for that type.  In this example,
>even if you wrote "(char *)" in front of this, it wouldn't save you;
>the compiler would still be entitled to believe that the intermediate
>cast value meant something.  The casts in the underlying macros
>ITEM_FREQUENCY and so on are equally unsafe.
>

OK. So the solution is to ditch the casts altogether, and then do plain
pointer arithmetics like this:

#define ITEM_INDEXES(item)            (item)
#define ITEM_NULLS(item,ndims)        (ITEM_INDEXES(item) + (ndims))
#define ITEM_FREQUENCY(item,ndims)    (ITEM_NULLS(item, ndims) + (ndims))
#define ITEM_BASE_FREQUENCY(item,ndims)    (ITEM_FREQUENCY(item, ndims) + sizeof(double))

Or is that still relying on alignment, somehow?


regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services 



pgsql-hackers by date:

Previous
From: Andrew Gierth
Date:
Subject: Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)
Next
From: "Elif Ak"
Date:
Subject: GSoD Introductory Tutorial