Possible Memory Leak on Supervisor


When running addChild/removeChild in a loop using the Supervisor API, we noticed a memory leak. I don't know if this is related to #DPP-72.

We have tried to replace the StateT monad being used in ManagedProcess to be Strict, and created a NFData instance for the Supervisor State, and that doesn't seem to stop the leak. We will add more ps files with profiling as we go.

Here is the code we are using for the test:


Attached is one ps




April 27, 2015, 5:36 PM

ash sneakers wedge
ash sneakers on sale http://www.generacionexa.org/

Tavis Rudd
March 18, 2014, 10:50 PM

We think the solution is to clean up the restarter in handleDeleteChild but it's in RestrictedProcess so it seems we can't kill the restarter without converting it to unrestricted Process. Would that mess things up?

Tim Watson
March 18, 2014, 9:48 PM

We've found the cause of the leak.... We're working on a patch.

- you guys rock! Thanks to you all for your work investigating and tracking this down.

Tavis Rudd
March 18, 2014, 9:31 PM

We've found the cause of the leak. The StarterProcess restarterPid variant of ChildStart is leaking restarter processes when used with dynamic supervision. They are eventually cleaned up when the supervisor terminates but for long running dynamic pools under a supervisor that does not exit, the combo of startNewChild / terminateChild+deleteChild leaks a process per iteration. We're working on a patch.

Tim Watson
March 12, 2014, 9:55 AM

No, I've fixed that in HEAD (development) by ensuring that the links are created. When I finally get around to testing this, I suspect we'll find that it really is not a leak at all, but I just haven't found to for it yet. Sorry - as soon I can, I will, promise!


Tim Watson


Román González


External issue ID





Fix versions