SIGSEGV in GrantLockLocal() - Mailing list pgsql-hackers

From Richard Guo
Subject SIGSEGV in GrantLockLocal()
Date
Msg-id CAMbWs4_dNX1SzBmvFdoY-LxJh_4W_BjtVd5i008ihfU-wFF=eg@mail.gmail.com
Whole thread Raw
Responses Re: SIGSEGV in GrantLockLocal()
List pgsql-hackers
Recently, I've encountered a core dump several times on master, with a
backtrace like the one below.  This one happened on 0f23dedc9.  I was
running some fuzz testing and had started around 20 sessions
concurrently.

(gdb) bt
#0  in GrantLockLocal at lock.c:1758
#1  in GrantAwaitedLock at lock.c:1840
#2  in LockErrorCleanup at proc.c:809
#3  in AbortTransaction at xact.c:2846
#4  in AbortCurrentTransactionInternal at xact.c:3520
#5  in AbortCurrentTransaction at xact.c:3449
#6  in PostgresMain at postgres.c:4535
#7  in BackendMain at backend_startup.c:107
#8  in postmaster_child_launch at launch_backend.c:274
#9  in BackendStartup at postmaster.c:3391
#10 in ServerLoop at postmaster.c:1678
#11 in PostmasterMain at postmaster.c:1376
#12 in main at main.c:224

It seems that the lock request is not granted as expected, since
locallock->lockOwners is a NULL pointer.

(gdb) p locallock->lockOwners
$4 = (LOCALLOCKOWNER *) 0x0
(gdb) p locallock->numLockOwners
$5 = 0
(gdb) p locallock->maxLockOwners
$6 = 8

Unfortunately, I don't have a reliable way to trigger this issue.  I'm
wondering if anyone has any insights into what might be happening.

Thanks
Richard



pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: Logical Replication of sequences
Next
From: John Naylor
Date:
Subject: Re: CRC32C Parallel Computation Optimization on ARM