Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1odHIb-0005BT-4x for pgsql-hackers@arkaria.postgresql.org; Tue, 27 Sep 2022 20:35:25 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1odHIZ-0003LZ-W4 for pgsql-hackers@arkaria.postgresql.org; Tue, 27 Sep 2022 20:35:23 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1odHIZ-0003LQ-N4 for pgsql-hackers@lists.postgresql.org; Tue, 27 Sep 2022 20:35:23 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1odHIW-0000gv-3T for pgsql-hackers@postgresql.org; Tue, 27 Sep 2022 20:35:23 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 28RKZH9k3825455; Tue, 27 Sep 2022 16:35:17 -0400 From: Tom Lane To: Justin Pryzby cc: Robert Haas , pgsql-hackers@postgresql.org, Dilip Kumar Subject: Re: longfin and tamandua aren't too happy but I'm not sure why In-reply-to: <20220927200712.GH6256@telsasoft.com> References: <20220927200712.GH6256@telsasoft.com> Comments: In-reply-to Justin Pryzby message dated "Tue, 27 Sep 2022 15:07:12 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3825453.1664310917.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Sep 2022 16:35:17 -0400 Message-ID: <3825454.1664310917@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Justin Pryzby writes: > On Tue, Sep 27, 2022 at 02:55:18PM -0400, Robert Haas wrote: >> Both animals are running with -fsanitize=3Dalignment and it's not >> difficult to believe that the commit mentioned above could have >> introduced an alignment problem where we didn't have one before, but >> without a stack backtrace I don't know how to track it down. I tried >> running those tests locally with -fsanitize=3Dalignment and they passed= . > There's one here: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=3Dkestrel&dt=3D2= 022-09-27%2018%3A43%3A06 On longfin's host, the test_decoding run produces two core files. One has a backtrace like this: * frame #0: 0x000000010a36af8c postgres`ParseCommitRecord(info=3D'\x80',= xlrec=3D0x00007fa0678a8090, parsed=3D0x00007ff7b5c50e78) at xactdesc.c:10= 2:30 frame #1: 0x000000010a765f9e postgres`xact_decode(ctx=3D0x00007fa0680d= 9118, buf=3D0x00007ff7b5c51000) at decode.c:201:5 [opt] frame #2: 0x000000010a765d17 postgres`LogicalDecodingProcessRecord(ctx= =3D0x00007fa0680d9118, record=3D) at decode.c:119:3 [opt] frame #3: 0x000000010a76d890 postgres`pg_logical_slot_get_changes_guts= (fcinfo=3D, confirm=3Dtrue, binary=3Dfalse) at logicalfuncs.c= :271:5 [opt] frame #4: 0x000000010a76d320 postgres`pg_logical_slot_get_changes(fcin= fo=3D) at logicalfuncs.c:338:9 [opt] frame #5: 0x000000010a5a521d postgres`ExecMakeTableFunctionResult(sete= xpr=3D, econtext=3D0x00007fa068098f50, argContext=3D, expectedDesc=3D0x00007fa06701ba38, randomAccess=3D) at = execSRF.c:234:13 [opt] frame #6: 0x000000010a5c405b postgres`FunctionNext(node=3D0x00007fa068= 098d40) at nodeFunctionscan.c:95:5 [opt] frame #7: 0x000000010a5a61b9 postgres`ExecScan(node=3D0x00007fa068098d= 40, accessMtd=3D(postgres`FunctionNext at nodeFunctionscan.c:61), recheckM= td=3D(postgres`FunctionRecheck at nodeFunctionscan.c:251)) at execScan.c:1= 99:10 [opt] frame #8: 0x000000010a596ee0 postgres`standard_ExecutorRun [inlined] E= xecProcNode(node=3D0x00007fa068098d40) at executor.h:259:9 [opt] frame #9: 0x000000010a596eb8 postgres`standard_ExecutorRun [inlined] E= xecutePlan(estate=3D, planstate=3D0x00007fa068098d40, use_par= allel_mode=3D, operation=3DCMD_SELECT, sendTuples=3D, numberTuples=3D0, direction=3D1745456112, dest=3D0x00007fa067023848,= execute_once=3D) at execMain.c:1636:10 [opt] frame #10: 0x000000010a596e2a postgres`standard_ExecutorRun(queryDesc=3D= , direction=3D1745456112, count=3D0, execute_once=3D) at execMain.c:363:3 [opt] and the other * frame #0: 0x000000010a36af8c postgres`ParseCommitRecord(info=3D'\x80',= xlrec=3D0x00007fa06783a090, parsed=3D0x00007ff7b5c50040) at xactdesc.c:10= 2:30 frame #1: 0x000000010a3cd24d postgres`xact_redo(record=3D0x00007fa0670= 096c8) at xact.c:6161:3 frame #2: 0x000000010a41770d postgres`ApplyWalRecord(xlogreader=3D0x00= 007fa0670096c8, record=3D0x00007fa06783a060, replayTLI=3D0x00007ff7b5c507f= 0) at xlogrecovery.c:1897:2 frame #3: 0x000000010a4154be postgres`PerformWalRecovery at xlogrecove= ry.c:1728:4 frame #4: 0x000000010a3e0dc7 postgres`StartupXLOG at xlog.c:5473:3 frame #5: 0x000000010a7498a0 postgres`StartupProcessMain at startup.c:= 267:2 [opt] frame #6: 0x000000010a73e2cb postgres`AuxiliaryProcessMain(auxtype=3DS= tartupProcess) at auxprocess.c:141:4 [opt] frame #7: 0x000000010a745b97 postgres`StartChildProcess(type=3DStartup= Process) at postmaster.c:5408:3 [opt] frame #8: 0x000000010a7487e2 postgres`PostmasterStateMachine at postma= ster.c:4006:16 [opt] frame #9: 0x000000010a745804 postgres`reaper(postgres_signal_arg=3D) at postmaster.c:3256:2 [opt] frame #10: 0x00007ff815b16dfd libsystem_platform.dylib`_sigtramp + 29 frame #11: 0x00007ff815accd5b libsystem_kernel.dylib`__select + 11 frame #12: 0x000000010a74689c postgres`ServerLoop at postmaster.c:1768= :13 [opt] frame #13: 0x000000010a743fbb postgres`PostmasterMain(argc=3D, argv=3D0x00006000006480a0) at postmaster.c:1476:11 [opt] frame #14: 0x000000010a61c775 postgres`main(argc=3D8, argv=3D) at main.c:197:3 [opt] Looks like it might be the same bug, but perhaps not. I recompiled access/transam and access/rmgrdesc at -O0 to get the accurate line numbers shown for those files. Let me know if you need any more info; I can add -O0 in more places, or poke around in the cores. regards, tom lane