At Thu, 19 May 2022 17:16:03 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote in
> Justin Pryzby <pryzby@telsasoft.com> writes:
> > ./tmp_install/usr/local/pgsql/bin/postgres -D ./src/test/regress/tmp_check/data -c min_dynamic_shared_memory=1MB
> > TRAP: FailedAssertion("val > base", File: "../../../../src/include/utils/relptr.h", Line: 67, PID: 21912)
>
> Yeah, I see it too.
>
> > It looks like this may be pre-existing problem exposed by
> > commit e07d4ddc55fdcf82082950b3eb0cd8f728284c9d
>
> Agreed. Here I see
>
> #5 FreePageManagerInitialize (fpm=fpm@entry=0x7f34b3ddd300,
> base=base@entry=0x7f34b3ddd300 "") at freepage.c:187
> #6 0x000000000082423e in dsm_shmem_init () at dsm.c:473
>
> so that where we do
>
> relptr_store(base, fpm->self, fpm);
>
> the "relative" pointer value would have to be zero, making the case
> indistinguishable from a NULL pointer. We can either change the
> caller so that these addresses aren't the same, or give up the
> ability to store NULL in relptrs ... doesn't seem like a hard call.
>
> One interesting question I didn't look into is why it takes a nondefault
> value of min_dynamic_shared_memory to expose this bug.
The path is taken only when a valid value is given to the
parameter. If we don't use preallocated dsm, it is initialized
elsewhere. In those cases the first bytes of the base address (the
second parameter of FreePageManagerInitialize) are used for
dsa_segment_header so the relptr won't be zero (!= NULL).
It can be silenced by wasting the first MAXALIGN bytes of
dsm_main_space_begin..
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center