Question

Perl uses reference counting for GC, and it’s quite easy to make a circular reference by accident. I see that my program seems to be using more and more memory, and it will probably overflow after a few days.

Is there any way to debug memory leaks in Perl? Attaching to a program and getting numbers of objects of various types would be a good start. If I knew which objects are much more numerous than expected I could check all references to them and hopefully fix the leak.

Answer 1

It may be relevant that Perl never gives memory back to the system by itself: It’s all up to malloc() and all the rules associated with that.

Knowing how malloc() allocates memory is important to answering the greater question, and it varies from system to system, but in general most malloc() implementations are optimized for programs allocating and deallocating in stack-like orders. Perl uses reference-counting for tracking memory which means that deallocations which means (unlike a GC-based language which uses malloc() underneath) it is actually not all that difficult to tell where deallocation is going to occur, and in what order.

It may be that you can reorganize your program to take advantage of this fact- by calling undef($old_object) explicitly – and in the right order, in a manner similar to the way C-programmers say free(old_object);

For long-running programs (days, months, etc), where I have loads of load/copy/dump cycles, I garbage-collect using exit() and exec(), and where it’s otherwide unfeasible, I simply pack up my data structures (using Storable) and file descriptors (using $^F) and exec($0) – usually with an environment variable set like $ENV{EXEC_GC_MODE}, and you may need something similar even if you don’t have any leaks of your own simply because Perl is leaking small chunks that your system’s malloc() can’t figure out how to give back.

Of course, if you do have leaks in your code, then the rest of my advice is somewhat more relevant. It was originally posted to another question on this subject, but it didn’t explicitly cover long-running programs.

---

All perl program memory leaks will either be an XS holding onto a reference, or a circular data structure. Devel::Cycle is a great tool for finding circular references, if you know what structures are likely to contain the loops. Devel::Peek can be used to find objects with a higher-than-expected reference count.

If you don’t know where else to look, Devel::LeakTrace::Fast could be a good first place, but you’ll need a perl built for debugging.

If you suspect the leak is inside XS-space, it’s much harder, and Valgrind will probably be your best bet. Test::Valgrind may help you lower the amount of code you need to search, but this won’t work on Windows, so you’d have to port (at least the leaky portion) to Linux in order to do this.