home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / os / vms / 19480 < prev    next >
Encoding:
Text File  |  1992-12-17  |  3.6 KB  |  86 lines
  1. Newsgroups: comp.os.vms
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!swrinde!sdd.hp.com!ux1.cso.uiuc.edu!usenet.ucs.indiana.edu!logos.ucs.indiana.edu!hughes
  3. From: hughes@logos.ucs.indiana.edu (larry hughes)
  4. Subject: mail$ memory leak? 
  5. Message-ID: <BzF7DE.5AH@usenet.ucs.indiana.edu>
  6. Sender: news@usenet.ucs.indiana.edu (USENET News System)
  7. Nntp-Posting-Host: logos.ucs.indiana.edu
  8. Organization: University Computing Services News
  9. Date: Thu, 17 Dec 1992 20:24:49 GMT
  10. Lines: 74
  11.  
  12. Does anyone (besides me :-) believe there to be a memory leak in
  13. the MAIL$ API for VMS 5.5-x?
  14.  
  15. We have an application (the IUPOP3 pop3 mail server) whose working
  16. set and virtual pages grows monotonically over time.  Eventually,
  17. it crashes deep in the bowels of the API:
  18.  
  19. --------------------------------------------------------------------------
  20. %LIB-F-INSVIRMEM, insufficient virtual memory
  21. %TRACE-F-TRACEBACK, symbolic stack dump follows
  22. module name     routine name                     line       rel PC    abs PC
  23.                                                            0004921A  0004921A
  24.                                                            000492B5  000492B5
  25.                                                            00049512  00049512
  26. IUPOP3_VMS      mail_open_file_context           3434      00000047  00012EDB
  27. IUPOP3_COMMANDS pop_pass                         1128      000000FE  00010C6A
  28. IUPOP3          process_thread                   4473      00000145  0001076D
  29. IUPOP3          main                             3770      000004A9  0000F6A9
  30. --------------------------------------------------------------------------
  31.  
  32. The crash occurs during a call to mail$mailfile_open().
  33.  
  34. I have a high degree of confidence that it's not the application,
  35. as calloc() is called in only once place, and I've taken pains to
  36. be sure that a corresponding free() is done when necessary.
  37.  
  38. To test further, I have a little program that loops infinitely, doing
  39. nothing more than checking for new mail message on my own mail file.
  40. I never have new mail, as I forward it to another machine.
  41.  
  42. The test program has been running at low priority (2) now for nearly a
  43. day.  After a few loop iterations, Monitor reported that the Working
  44. Set was 1100 and the Virtual Pages was 6576.  Now, after 20 hours and
  45. 13,500 iterations, it reports a Working Set of 2412 and Virtual Pages
  46. is at 7856.  Just like the real application, I'm sure it will crash
  47. eventually.
  48.  
  49. Here's pseudo-code of the API calling sequence:
  50.  
  51.   while (1)
  52.   {
  53.     mail$user_begin
  54.       mail$user_get_info
  55.       mail$mailfile_begin
  56.         mail$mailfile_open
  57.           mail$message_begin
  58.             mail$message_select
  59.           mail$message_end
  60.         mail$mailfile_close
  61.       mail$mailfile_end
  62.     mail$user_end
  63.   }
  64.  
  65. (I know this is a hard way to check for the new mail count, but the
  66. test program emulates the behavior of the real application.)
  67.  
  68. Questions:
  69.  
  70. 1. Is anybody else experiencing something like this in your own
  71.    homegrown application that uses the mail API?
  72.  
  73. 2. Is there a way for me to make the test program crash by limiting
  74.    its virtual pages to something small when it starts?  DSNlink wants 
  75.    a dump when it crashes, so I'll RUN/DETACH/DUMP it.  But I don't 
  76.    want to wait a week for it to crash.
  77.  
  78.  //==================================================================\\
  79. ||      Larry J. Hughes, Jr.       |        hughes@indiana.edu        ||
  80. ||       Indiana University        | "The person who knows everything ||
  81. ||  University Computing Services  |        has a lot to learn."      ||
  82.  \\===================================================================//
  83.  
  84.  
  85.  
  86.