Ralph Castain
unread,Feb 1, 2026, 5:10:23 PM (5 days ago) Feb 1Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to pm...@googlegroups.com
Hi folks
Been working on some memory leak cleanup for the PMIx library and hit something that is obvious when you look at it hard enough, but easily overlooked.
PMIx initializes the Libevent library during PMIx_Init and creates its own event base(s). Upon finalize, the library free’s the event bases that it used. However, Libevent “leaks” a little bit of memory with each event base - the only way to completely clean it up is to shutdown the library.
The problem arises if the host process is also using Libevent - either directly or through another dependency. If PMIx shuts down Libevent, then it is shutdown for _every_ library that is using it in that process. So making PMIx run “valgrind clean” has an unintended consequence of requiring that no other library in the process use Libevent after the host process calls PMIx_Finalize.
Of course, there is no way for PMIx to know if other libraries in the host process are using Libevent. One solution, though, would be to allow passing of an attribute to PMIx_Finalize (and the server and tool versions) directing PMIx to not finalize Libevent. Another solution, of course, is for PMIx to simply leak the Libevent memory - it’s only a few bytes per event base. Annoying to those striving for memory cleanliness, but...perhaps a solution.
Similarly, PMIx will create an HWLOC topology tree (either by directly discovering the topology or attaching to a shared memory instance of the tree) that it makes available to its host process. If the host process defines an abstraction variable (e.g., mytopology = pmix-topology), then when PMIx finalizes and destroys the topology, the host process will be left with a stale address pointer. Nothing PMIx itself can do about the stale pointer, but we could provide an attribute to direct PMIx to leave the topology tree instanced. Alternatively, of course, the host process can define the topology tree itself and pass its pointer to PMIx - thus letting the host process control when the tree is destroyed.
I bring this up because I have discovered at least one PMIx consumer (OpenMPI) that is exposed to both of these problems in their code base. I’m not sure which of the solutions they will choose, or if others can/will be devised. Either way, I figured maybe I should warn others in case they have similar issues.
Ralph