PG signal handler and non-reentrant malloc/free calls - Mailing list pgsql-hackers

From Nikhil Sontakke
Subject PG signal handler and non-reentrant malloc/free calls
Date
Msg-id AANLkTin1E14_8+cU2Pa0Y4c-8zNMkPkogFgQEsPaEsAh@mail.gmail.com
Whole thread Raw
Responses Re: PG signal handler and non-reentrant malloc/free calls  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
Hi, <br /><br />I believe we have a case where not holding off interrupts while doing a malloc() can cause a deadlock
dueto system or libc level locking. In this case, a pg_ctl stop in fast mode was resorted to and that caused a backend
tohandle the interrupt when it was inside the malloc call. Now as part of the abort processing, in the subtransaction
cleanupcode path, this same backend tried to clear memory contexts, leading to an eventual free() call. The free() call
triedto take the same lock which was already held by malloc() earlier resulting into a deadlock! Will try to get the
callstack if needed.<br /><br />The malloc/free functions are known to be not re-entrant. Doesn't it make sense to hold
offinterrupts 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.<br /><br />Comments, thoughts?<br
/><br/>Regards,<br />Nikhils<br /> 

pgsql-hackers by date:

Previous
From: Marko Tiikkaja
Date:
Subject: Re: wCTE: about the name of the feature
Next
From: Heikki Linnakangas
Date:
Subject: Re: PG signal handler and non-reentrant malloc/free calls