http://www.perlmonks.org?node_id=543730

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

This is an odd one (for me, a perl admin/user/developer of 5 years).

A friend has a fleet of P166MMX, 32MB laptops he is attempting to turn into digital photo frames. We installed Debian etch pre-release (with kernel 2.6.15, Perl 5.8.8) on one to use as a prototype. Everything went well, I did various things to keep the memory usage down such as removing excess gettys, replacing bash, etc ... and then we hit this stupid snag.

I have tried both the original CPAN as well as CPAN Plus. Both of them do the same thing. When I attempt to install a module through CPAN, at first things seem to be going ok, then it hits the part where it is building the module tree (before it actually fetches and installs the module). At this point, the system becomes unusable. CPAN eventually responds to a Ctrl-C, but it takes several seconds, and the process cleanup takes several minutes unless sent SIGKILL.

I have examined the process while this is happening. Top shows that the perl process is continuing to allocate memory, and spending time alternating between the R and D states. At no time is the perl process actually consuming 100% CPU or anywhere near it. An examination with strace shows that all that is happening is that time(NULL) is called hundreds of times per second, and brk() is occasionally called, always with a larger argument than the previous brk().

Based on this, it seems like the perl is stuck in an infinite memory allocation loop. But I don't know if it is really infinite. The process grows to an 18MB resident size, everything else is paged out, and the VIRT size keeps growing (last one I saw was around 80MB), until eventually my ssh session is paged out for too long and the connection dies. (He lives far enough away where doing this in person doesn't make sense.)

I have attempted to set /proc/sys/vm/overcommit_memory to 1 with the same results. Does anyone else have a better idea what is going on here? Does this perhaps have to do with Debian's perl using internal malloc rather than system malloc? Is there some kind of race going on due to the limited resources of the machine?

Running perl on some test scripts seems ok, but I'm not sure what a good test case for this is.

I used debian.pkgs.cpan.org for most of the stuff he needs, but on the other stuff it isn't packaged and has lots of dependencies which I'd prefer not to have to hand install...