From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Why is lorikeet so unstable in v14 branch only?
Date: Sun, 27 Mar 2022 12:31:23 -0400
Message-ID: <278381.1648398683@sss.pgh.pa.us> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, andrew@dunslane.net, andres@anarazel.de, pgsql-hackers@lists.postgresql.org
Subject: Re: Why is lorikeet so unstable in v14 branch only?
In-Reply-To: <278381.1648398683@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox