From: | Nikhil Sontakke <nikhil(dot)sontakke(at)enterprisedb(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | PG signal handler and non-reentrant malloc/free calls |
Date: | 2011-02-28 12:04:03 |
Message-ID: | AANLkTin1E14_8+cU2Pa0Y4c-8zNMkPkogFgQEsPaEsAh@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
I believe we have a case where not holding off interrupts while doing a
malloc() can cause a deadlock due to system or libc level locking. In this
case, a pg_ctl stop in fast mode was resorted to and that caused a backend
to handle the interrupt when it was inside the malloc call. Now as part of
the abort processing, in the subtransaction cleanup code path, this same
backend tried to clear memory contexts, leading to an eventual free() call.
The free() call tried to take the same lock which was already held by
malloc() earlier resulting into a deadlock! Will try to get the call stack
if needed.
The malloc/free functions are known to be not re-entrant. Doesn't it make
sense to hold off interrupts while doing such calls inside the AllocSet* set
of functions? Thankfully the locations are not very many.
AllocSetContextCreate, AllocSetAlloc and AllocSetFree seem to be the only
candidates.
Comments, thoughts?
Regards,
Nikhils
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2011-02-28 12:27:08 | Re: PG signal handler and non-reentrant malloc/free calls |
Previous Message | Marko Tiikkaja | 2011-02-28 10:13:16 | Re: wCTE: about the name of the feature |