Re: v15b1: FailedAssertion("segment_map->header->magic == (DSA_SEGMENT_HEADER_MAGIC ^ area->control->handle ^ index)", File: "dsa.c", ..)

On Wed, Apr 12, 2023 at 7:46 AM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
> Unfortunately:
> (gdb) p area->control->handle
> $3 = 0
> (gdb) p segment_map->header->magic
> value has been optimized out
> (gdb) p index
> $4 = <value optimized out>

Hmm, well index I can find from parameters:

> #2 0x0000000000991470 in ExceptionalCondition (conditionName=<value optimized out>, errorType=<value optimized out>, fileName=<value optimized out>, lineNumber=1770) at assert.c:69
> #3 0x00000000009b9f97 in get_segment_by_index (area=0x22818c0, index=<value optimized out>) at dsa.c:1769
> #4 0x00000000009ba192 in dsa_get_address (area=0x22818c0, dp=1099511703168) at dsa.c:953

We have dp=1099511703168 == 0x10000012680, so index == 1 and the rest
is the offset into that segment. It's not the initial segment in the
main shared memory area created by the postmaster with
dsa_create_in_place() (that'd be index 0), it's in an extra segment
that was created with shm_open(). We managed to open and mmap() that
segment, but it contains unexpected garbage.

Can you print *area->control? And then can you see that the DSM
handle is in index 1 in "segment_handles" in there? Then can you see
if your system has a file with that number in its name under
/dev/shm/, and can you tell me what "od -c /dev/shm/..." shows as the
first few lines of stuff at the top, so we can see what that
unexpected garbage looks like?

Side rant: I don't think there's any particular indication that it's
the issue here, but while it's on my mind: I really wish we didn't
use random numbers for DSM handles. I understand where it came from:
the need to manage SysV shmem keyspace (a DSM mode that almost nobody
uses, but whose limitations apply to all modes). We've debugged
issues relating to handle collisions before, causing unrelated DSM
segments to be confused, back when the random seed was not different
in each backend making collisions likely. For every other mode, we
could instead use something like (slot, generation) to keep collisions
as far apart as possible (generation wraparound), and avoid collisions
between unrelated clusters by using the pgdata path as a shm_open()
prefix. Another idea is to add a new DSM mode that would use memfd
and similar things and pass fds between backends, so that the segments
are entirely anonymous and don't need to be cleaned up after a crash
(I thought about that while studying the reasons why PostgreSQL can't
run on Capsicum (a capabilities research project) or Android (a
telephone), both of which banned SysV *and* POSIX shm because
system-global namespaces are bad).