Re: Segmentation fault on proc exit after dshash_find_or_insert

Hi,

On 2025-12-04 11:06:20 +0900, Amit Langote wrote:
> On Thu, Dec 4, 2025 at 12:33 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > I don't agree. You *cannot* rely on lwlocks working after an error before you
> > have called LWLockReleaseAll(). I.e. currently *any* use of lwlocks in
> > before_shmem_exit is unsafe. The only reason we haven't really noticed that is
> > that most of the top-level error handlers (i.e. sigsetjmp()s) do an
> > AbortCurrentTransaction(), which does an LWLockReleaseAll() if in a tx, and
> > most lwlock acquisitions happen within a transaction. But if you ever do stuff
> > outside of a transaction, the AbortCurrentTransaction() won't do
> > LWLockReleaseAll(), and you're in trouble, as the case here.
> >
> > IOW, I think we need to do LWLockReleaseAll() at the top of proc_exit(), at
> > least in case of FATAL errors.
>
> Oh, so not at the top of not shmem_exit() as Rahila has proposed?

Oh, ontop of shmem_exit() seems fine, what I was trying to express was that it
should happen unconditionally at the start of exit processing, not just at the
tail.

> > We probably should add a note to LWLockReleaseAll() indicating that we rely on
> > LWLockReleaseAll() working even if CreateLWLocks()/InitializeLWLocks() etc
> > hasn't yet been called...
>
> Makes sense. AFAICS, num_held_lwlocks would be 0 in that case, so
> LWLockReleaseAll() would be a no-op.

Right. I just meant we should add a comment noting that we rely on that
fact...

Greetings,

Andres Freund