From: SourceForge.net <no...@so...> - 2012-02-23 04:18:11
|
Bugs item #2833447, was opened at 2009-08-06 17:54 Message generated for change (Comment added) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2833447&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: APIs Group: v4.0 >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: yachen (yachen) >Assigned to: Mark Miesfeld (miesfeld) Summary: memory leak in some function within rexx.dll and rexxapi.dll Initial Comment: Our software relies on REXX to provide key business functionality. It evolved together with REXX versions over many years. Recently in our test-run of REXX v4.0, our testing software(Purify) detects there are a couple of memory leak concerns on two REXX internal functions: RexxPullQueue within REXXAPI.DLL RexxSetProcessMessages within REXX.DLL We would highly appreciate if any developer can shed some light on the impact of these memory leaks before we make decision to pilot REXX v4.0 in some production environment. We run the exact same test case on REXX v3.2 and Purify didn't report issue. I've attached 2 reports generated by Purify, both run under REXX v3.2 and REXX v4.0. Both REXX interpreters are installed on Windows XP SP2, Thanks. ---------------------------------------------------------------------- >Comment By: Mark Miesfeld (miesfeld) Date: 2012-02-22 20:18 Message: I'm going to close this as out of date. The submitter has not responded to our questions in 2 and 1/2 years. The assertion that RexxSetProcessMessages() was causing a memory leak could not possibly have been correct. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-08-16 21:40 Message: yachen, We have not heard back from you on this. As Rick pointed out, RexxSetProcessMessages could not cause a memory because it simply returned TRUE. If it is the case that you and your colleagues no longer believe your Purify reports to be valid, and no longer believe there is a memory leak, could you let us know so that we can close this bug. Or, if you have more data that supports your claim, could you add it to the bug report so that we can do something about it. Thanks. ---------------------------------------------------------------------- Comment By: Rick McGuire (bigrixx) Date: 2009-08-09 17:29 Message: We're going to need some more information to debug this problem. Your purify logs are somewhat suspect, as there's no possible way that RexxSetProcessMessages could possibly be causing a message leak, which leads me to believe that the RexxPullFromQueue report might also be incorrect. I have done some testing of my own, and I have not been able to detect any memory leaks in RessPullFromQueue. ---------------------------------------------------------------------- Comment By: yachen (yachen) Date: 2009-08-09 17:25 Message: Hi, The installation file we are using comes with the name 'ooRexx-4.0.0-5014-rc3.i386.exe', when I run REXX -v, it shows the following information Open Object Rexx Version 4.0.0 Build date: Jul 26 2009 Addressing Mode: 32 Copyright (c) IBM Corporation 1995, 2004. Copyright (c) RexxLA 2005-2009. All Rights Reserved. This program and the accompanying materials are made available under the terms of the Common Public License v1.0 which accompanies this distribution. http://www.oorexx.org/license.html ---------------------------------------------------------------------- Comment By: Rick McGuire (bigrixx) Date: 2009-08-06 18:15 Message: What buile of 4.0 are you running with? Earlier in the beta there were some memory leaks associated with RexxPullQueue that have been fixed. I am extremely certain there are none in the latest beta. The data for RexxSetProcessMessages() is most puzzling, since that API is a compatibitly stub that merely returns TRUE. There is no possible way that API could be leaking memory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2833447&group_id=119701 |