in reply to memory not freed after perl exits. Solaris.

From your 'uname' output, you are running on Solaris 10. There is virtually no way that this is an OS problem. There are really only 3 possibilities:
  1. your program is not really ending, or becomes a zombie. This has already been discussed at length.
  2. Your program is interacting with another process on the system, and that process is sucking up the memory
  3. (highly unlikely) Either your program or another process is doing some sort of persistent memory allocation that is not being freed. shared memory is the only thing I can think of here
(1) and (2) can be checked by calls to 'ps aux' before and after runs of your program. The process sizes are included in this list. It's usually not hard to spot the memory hogs. In the unlikely event of (3), you can check with 'ipcs -m'

Update: I thought of another, less unlikely instance of (3). ramdisks (or tmpfs filesystems) can also suck up memory. 'df' will show these

fnord

  • Comment on Re: memory not freed after perl exits. Solaris.

Replies are listed 'Best First'.
Re^2: memory not freed after perl exits. Solaris.
by JavaFan (Canon) on Nov 23, 2010 at 17:51 UTC
    And even if there are zombies, it shouldn't take up much memory. Only thing a zombie needs is its exit value - which is a single byte. There will be a bit more overhead than a single byte, but a zombie should not hold on to memory it created in userland. You're more likely to run out of PIDs than out of memory due to zombies.