Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


#39 Memory Leak Using ActiveX/OLE

Mark Miesfeld
Lee Peedin

When making repeated calls to a sub-routine that uses
ActiveX, memory usage continues to climb. An
attached sample program demostrates this. Open the
Processes Tab of the Task Manager and at each of the
3 "pull" statements in the code, make a note of the
required memory. Have tested this code side by side
with ObjRexx 2.1.3 and leak appears to be worse.


  • Rick McGuire
    Rick McGuire

    Logged In: YES
    Originator: NO

    Mark, could you take a look at this one? This might the same problem you looked at a little bit ago with syssleep(). The memory bumps up a little with each iteration of the loop, but it might just be the problem of misinterpreting the numbers reported by the task manager monitor.

  • Mark Miesfeld
    Mark Miesfeld

    Logged In: YES
    Originator: NO

    Yes, I will take a look at this again. I looked at quite some time ago, and I did think it was a mis-interpetation of the numbers.

    It should just be a matter of double-checking what I did before.

  • Mark Miesfeld
    Mark Miesfeld

    Logged In: YES
    Originator: NO

    There is no memory leak here.

    Lee, a couple of notes on this. A memory leak is not that subsequent memory usage is higher than initial memory usage. A memory leak is when a repetitive sequence continually increases memory usage. If the sequence is run long enough, eventually all memory in the system is exhausted. 3 data points are not sufficient to determine this.

    I altered Lee's program to run forever and print out snapshots of the memory usage. Rather than show a memory leak, this showed that memory usage is remarkably stable. I'm going to attach both the program and a log of running it for several hours.

    Here are some excerpts to show this:

    (Well I realized that SourceForge's reformatting screws up the columns. Looking at the log itself will show this better.)


    PsList 1.26 - Process Information Lister
    Copyright (C) 1999-2004 Mark Russinovich
    Sysinternals - www.sysinternals.com

    All memory values are displayed in KB.
    Abbreviation key:
    VM Virtual Memory
    WS Working Set
    Priv Private Virtual Memory
    Priv Pk Private Virtual Memory Peak
    Faults Page Faults
    NonP Non-Paged Pool
    Page Paged Pool

    Process memory detail for SDC18PCH91:

    Name Pid VM WS Priv Priv Pk Faults NonP Page
    rexx 3880 41672 5980 3968 3972 1553 4 70
    rexx 3880 43280 7028 3632 4028 3791 4 70
    rexx 3880 43280 7064 3656 4028 5087 4 70
    rexx 3880 43280 7064 3656 4028 5106 4 70
    rexx 3880 43280 7056 3656 4028 6416 4 70
    rexx 3880 43280 7040 3632 4028 7585 4 70
    rexx 3880 43280 7048 3644 4028 7606 4 70

    When you look at that you see the initial working set is 5980 KB, then goes to 7028, then to 7064. This is of course similar to Lee's 3 data points. However, then the working set drops back down to 7040.

    Running this test for a little over 3 hours shows that the working set never goes over 7096. The peak private virtual memory stays at exactly 4028 the entire time. In addition, you see that the page fault number continually climbs until it is well over 300,000, yet the working set never reaches 7100. That paints a picture of continuous memory allocation / memory free / memory reuse, with no leak.

    rexx 3880 43792 7000 3588 4028 366721 4 70
    rexx 3880 43792 7068 3660 4028 368207 4 70
    rexx 3880 43792 7068 3660 4028 368225 4 70
    rexx 3880 43792 7064 3656 4028 369882 4 70
    29 - do objProcess over colProcessList
    18 - call getinfo(aa)
    Error 4 running C:\work.ooRexx\other\bugs\bug.1145693\myTestMemory.rex line 29: Program int
    Error 4.1: Program interrupted with HALT condition

    (Lee - I'm marking the resolution as invalid and the status as pending. You should review my conclusions and, if you agree, change the status to closed.)

  • Mark Miesfeld
    Mark Miesfeld

    Logged In: YES
    Originator: NO

    File Added: memory.log

  • Mark Miesfeld
    Mark Miesfeld

    Logged In: YES
    Originator: NO

    File Added: myTestMemory.rex

  • Logged In: NO

    Sorry it has taken me so long to get back to you on this - Symposium, etc. :-)

    I concur with your analysis of this and agree that this bug report can be closed. I would do it, but for some unknown reason I am not able to log into SourceForge with the same user ID I entered this bug report with.

    Therefore, I will be more than happy for any of the Development team to close this on my behalf




Cancel   Add attachments