Re: Segmentation fault on proc exit after dshash_find_or_insert

On Wed, Dec 17, 2025 at 19:37 Rahila Syed <rahilasyed90@gmail.com> wrote:
> Hi Amit,
>>      /*
>>       * Release any LWLocks we might be holding, before running callbacks that
>> -     * may detach the memory containing those locks.
>> +     * may detach the memory containing those locks. Releasing all the locks
>> +     * ensures that any callbacks executed afterward will be able to acquire
>> +     * any lock.
>>       */
>>
>> Hmm, I'm not sure I follow.  Maybe it has to do with something you
>> were trying to do when you ran into this bug, but why would callbacks
>> be acquiring locks after an error and why would it be safe to do so?
>
> It seems common for both before and on shmem exit callbacks to acquire locks.
> For instance, RemoveTempRelationsCallback eventually calls performDeletion,
> which acquires an LW lock.
>>
>> Are you saying that LWLockReleaseAll() cleans up unsafe-to-access
>> locks so that new ones can be taken after that point?
>
> Yes, what I mean is that acquiring a lock within a callback will work,
> regardless of whether it was held when the error occurred, since we ensure
> all locks are released before executing the callbacks.

I get confused easily it seems. :-)

You’re right, this is how I understood it too the last time we were
here, but I remembered something Andres wrote upthread and interpreted
it wrongly in my head.

Also, now that I read the full comment, the first sentence doesn’t
look quite right; callbacks don’t detach segments.  How about
rewording the comment a bit, like this:

/*
 * Release any LWLocks we might be holding before callbacks run. This
 * prevents accessing locks in detached DSM segments and allows callbacks
 * to acquire new locks.
*/

--
Thanks, Amit Langote