mr_mischief has asked for the wisdom of the Perl Monks concerning the following question:

I have a daemon (tpop3d) which embeds a perl so administrators can plug in a Perl subroutine to authenticate POP3 users. Everything works very well. The problem I'm having is that there are no known memory leaks in the server, but it leaks memory pretty badly when I use my authentication plugin.

The maintainter of the server proper doesn't actively use perl for authentication, using another authentication module instead. I was wondering if, since perl holds on to lexicals at the end of a scope, waiting to reenter that scope, it would be a good idea in such a situation to go with globals or locals. I could just restart the process every twelve hours or so, but it doesn't seem to be right that a 2 meg process makes it up to 18 megs if left running for five days.

Is there any way to keep perl from using additional memory over time?

Chris

Replies are listed 'Best First'.
Re: memory leak with embedded perl
by perrin (Chancellor) on Dec 18, 2001 at 01:27 UTC
    There's no advantage to globals over lexicals in terms of memory used. You could try undef'ing your variables at the end of your routine.
      I tried that already to no avail. I know little enough about the perl core that the idea of running Purify or ElectricFence over it embedded in another program makes flashbacks to some of the smaller auto accidents in which I've been involved seem like falling off the couch laughing. There must be something that's causing the leaks, but I have limited time and desire to find it myself. As much as I dislike the idea of using cron to relaunch the program or putting an exec() loop in the server daemon, I'm afraid those are starting to look like my options.

      Actually, I think if I exit the Perl program that get loaded, the embedded perl gets chucked and reinitialized. Perhaps that would be my best bet. Still, if anyone has any suggestions which would lead to a cleaner solution, I'd love to know.
        Honestly, things like this are very often due to something in your code. Why don't you try posting the smallest example you can create that still leaks and let people look at it? You might find the problem just by pulling bits out if it until it stops leaking.