From: hughes@logos.ucs.indiana.edu (larry hughes)
Subject: mail$ memory leak? 
Organization: University Computing Services News
Date: Thu, 17 Dec 1992 20:24:49 GMT

Does anyone (besides me :-) believe there to be a memory leak in
the MAIL$ API for VMS 5.5-x?

We have an application (the IUPOP3 pop3 mail server) whose working
set and virtual pages grows monotonically over time.  Eventually,
it crashes deep in the bowels of the API:

--------------------------------------------------------------------------
%LIB-F-INSVIRMEM, insufficient virtual memory
%TRACE-F-TRACEBACK, symbolic stack dump follows
module name     routine name                     line       rel PC    abs PC
                                                           0004921A  0004921A
                                                           000492B5  000492B5
                                                           00049512  00049512
IUPOP3_VMS      mail_open_file_context           3434      00000047  00012EDB
IUPOP3_COMMANDS pop_pass                         1128      000000FE  00010C6A
IUPOP3          process_thread                   4473      00000145  0001076D
IUPOP3          main                             3770      000004A9  0000F6A9
--------------------------------------------------------------------------

The crash occurs during a call to mail$mailfile_open().

I have a high degree of confidence that it's not the application,
as calloc() is called in only once place, and I've taken pains to
be sure that a corresponding free() is done when necessary.

To test further, I have a little program that loops infinitely, doing
nothing more than checking for new mail message on my own mail file.
I never have new mail, as I forward it to another machine.

The test program has been running at low priority (2) now for nearly a
day.  After a few loop iterations, Monitor reported that the Working
Set was 1100 and the Virtual Pages was 6576.  Now, after 20 hours and
13,500 iterations, it reports a Working Set of 2412 and Virtual Pages
is at 7856.  Just like the real application, I'm sure it will crash
eventually.

Here's pseudo-code of the API calling sequence:

  while (1)
  {
    mail$user_begin
      mail$user_get_info
      mail$mailfile_begin
        mail$mailfile_open
          mail$message_begin
            mail$message_select
          mail$message_end
        mail$mailfile_close
      mail$mailfile_end
    mail$user_end
  }

(I know this is a hard way to check for the new mail count, but the
test program emulates the behavior of the real application.)

Questions:

1. Is anybody else experiencing something like this in your own
   homegrown application that uses the mail API?

2. Is there a way for me to make the test program crash by limiting
   its virtual pages to something small when it starts?  DSNlink wants 
   a dump when it crashes, so I'll RUN/DETACH/DUMP it.  But I don't 
   want to wait a week for it to crash.

 //==================================================================\\
||      Larry J. Hughes, Jr.       |        hughes@indiana.edu        ||
||       Indiana University        | "The person who knows everything ||
||  University Computing Services  |        has a lot to learn."      ||
 \\===================================================================//