From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
cc: Andres Freund <andres@anarazel.de>, pgsql-hackers@lists.postgresql.org
Subject: Re: Why is lorikeet so unstable in v14 branch only?
In-reply-to: <f6d7b1f1-da4d-8806-a988-27e82acf65a0@dunslane.net>
References: <136102.1648320427@sss.pgh.pa.us>
 <20220326194948.mksfw6z3fysojpxx@alap3.anarazel.de>
 <aee3de02-1e5d-ae0a-c3e7-23cb1ef8cd70@dunslane.net>
 <167387.1648329583@sss.pgh.pa.us>
 <0b9defaa-07a3-7329-4f9d-5fc2c4a89170@dunslane.net>
 <174838.1648332620@sss.pgh.pa.us>
 <f6d7b1f1-da4d-8806-a988-27e82acf65a0@dunslane.net>
Comments: In-reply-to Andrew Dunstan <andrew@dunslane.net>
	message dated "Sun, 27 Mar 2022 09:42:05 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <278380.1648398683.1@sss.pgh.pa.us>
Date: Sun, 27 Mar 2022 12:31:23 -0400
Message-ID: <278381.1648398683@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/278381.1648398683%40sss.pgh.pa.us>
Precedence: bulk

Andrew Dunstan <andrew@dunslane.net> writes:
> It appears that it is using PS_USE_NONE, as it doesn't have any of the
> defines required for the other paths. I note that the branch for that in
> get_ps_display() doesn't set *displen, which looks a tad suspicious.

Indeed.  I forced it to use PS_USE_NONE on my Linux machine, and got
a core dump on the first try of the regression tests:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  __memmove_avx_unaligned_erms ()
    at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:516
516             VMOVNT  %VEC(0), (%r9)
(gdb) bt
#0  __memmove_avx_unaligned_erms ()
    at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:516
#1  0x00000000008299b3 in WaitOnLock (locallock=locallock@entry=0x2a5e700, 
    owner=owner@entry=0x2aba8f0) at lock.c:1831
#2  0x000000000082adc6 in LockAcquireExtended (
    locktag=locktag@entry=0x7ffc864fad90, lockmode=lockmode@entry=1, 
    sessionLock=sessionLock@entry=false, dontWait=dontWait@entry=false, 
    reportMemoryError=reportMemoryError@entry=true, 
    locallockp=locallockp@entry=0x7ffc864fad88) at lock.c:1101
#3  0x000000000082861f in LockRelationOid (relid=1259, lockmode=1)
    at lmgr.c:117
#4  0x000000000051c5ed in relation_open (relationId=1259, 
    lockmode=lockmode@entry=1) at relation.c:56
...

(gdb) f 1
#1  0x00000000008299b3 in WaitOnLock (locallock=locallock@entry=0x2a5e700, 
    owner=owner@entry=0x2aba8f0) at lock.c:1831
1831                    memcpy(new_status, old_status, len);
(gdb) p len
$1 = -1

Problem explained, good detective work!

> And maybe there's a good case for also
> surrounding some of the code in WaitOnLock() with "if (len) ..."

+1.  I'll make it so, and check the other callers too.

Once I push this, you should remove the update_process_title hack
from lorikeet's config, since that was just a workaround until
we tracked down the problem, which I think we just did.

			regards, tom lane