Re: SIGSEGV in GrantLockLocal()

On 18/12/2024 08:17, Richard Guo wrote:
> 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.

I don't know how that can happen, but I suspect commit 3c0fd64fec 
because it changed things in that area. If you can find a way to 
reproduce that even sporadically, that would be very helpful!

-- 
Heikki Linnakangas
Neon (https://neon.tech)