From: SourceForge.net <no...@so...> - 2007-04-23 18:39:50
|
Bugs item #1145693, was opened at 2005-02-21 13:38 Message generated for change (Settings changed) made by wdashley You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=1145693&group_id=119701 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: External Functions Group: v3.0beta >Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: pragmatic_lee (pragmatic_lee) Assigned to: Mark Miesfeld (miesfeld) Summary: Memory Leak Using ActiveX/OLE Initial Comment: 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. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-04-23 13:19 Message: Logged In: NO Mark, 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 Lee ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2007-04-19 15:40 Message: Logged In: YES user_id=191588 Originator: NO File Added: myTestMemory.rex ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2007-04-19 15:40 Message: Logged In: YES user_id=191588 Originator: NO File Added: memory.log ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2007-04-19 15:37 Message: Logged In: YES user_id=191588 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.) C:\work.ooRexx\other\bugs\bug.1145693>myTestMemory.rex 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 errupted 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.) ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2007-04-19 08:44 Message: Logged In: YES user_id=191588 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. ---------------------------------------------------------------------- Comment By: Rick McGuire (bigrixx) Date: 2007-04-19 08:35 Message: Logged In: YES user_id=1125291 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=1145693&group_id=119701 |