[rdnzl-devel] Possible leak with RDNZL 0.11.0/Lispworks 5
First off, thanks all for such useful bridging software. I converged on this after seeing leaks in my interactions with a DLL. My actual leak seems to occur on cast/unbox. However, in understanding what I may or may not be doing wrong, I present this situation: (loop for i from 0 do (rdnzl::invoke (rdnzl::invoke "System.Guid" "NewGuid") "ToString")) Nothing particularly inherent to Guids, just an example I could find that returns a string. This loop sits there eating up Ram in a situation where I'm guessing it shouldn't. Putting garbage collects in the middle of its execution doesn't change this, nor does running GC/clean-down after breaking out. I'm talking about post-collect menory usage continously rising. It stereotypes a situation in my usage pattern of calling into dotnet and returning strings. Is there something I'm doing wrong? An incorrect assumption about dotnet? Any help appreciated. Thanks, Matt
On Sun, 20 May 2007 17:35:15 -0500, "Matthew Lamari" <matt.lamari@gmail.com> wrote:
First off, thanks all for such useful bridging software.
You're welcome... :)
I converged on this after seeing leaks in my interactions with a DLL.
My actual leak seems to occur on cast/unbox. However, in understanding what I may or may not be doing wrong, I present this situation:
(loop for i from 0 do (rdnzl::invoke (rdnzl::invoke "System.Guid" "NewGuid") "ToString"))
You don't need the double colons - one of them is enough.
Nothing particularly inherent to Guids, just an example I could find that returns a string.
This loop sits there eating up Ram in a situation where I'm guessing it shouldn't. Putting garbage collects in the middle of its execution doesn't change this, nor does running GC/clean-down after breaking out. I'm talking about post-collect menory usage continously rising.
Are you talking about a "leak" on the Lisp side? How do you measure it? I don't understand how I am supposed to reproduce this. I just ran 500,000 iterations of the above and the allocation reported by (ROOM) is the same before and after the loop. Cheers, Edi.
Thank you for such a quick response. I was just typing up a retraction. "How do you measure it" <-- indeed. I concur that I have not provided a basis for reproduction of any issue here, and retract the bug report. I need to investigate further, apologise for the interruption, and thank you for your time. On 5/20/07, Edi Weitz <edi@agharta.de> wrote:
On Sun, 20 May 2007 17:35:15 -0500, "Matthew Lamari" <matt.lamari@gmail.com> wrote:
First off, thanks all for such useful bridging software.
You're welcome... :)
I converged on this after seeing leaks in my interactions with a DLL.
My actual leak seems to occur on cast/unbox. However, in understanding what I may or may not be doing wrong, I present this situation:
(loop for i from 0 do (rdnzl::invoke (rdnzl::invoke "System.Guid" "NewGuid") "ToString"))
You don't need the double colons - one of them is enough.
Nothing particularly inherent to Guids, just an example I could find that returns a string.
This loop sits there eating up Ram in a situation where I'm guessing it shouldn't. Putting garbage collects in the middle of its execution doesn't change this, nor does running GC/clean-down after breaking out. I'm talking about post-collect menory usage continously rising.
Are you talking about a "leak" on the Lisp side? How do you measure it? I don't understand how I am supposed to reproduce this. I just ran 500,000 iterations of the above and the allocation reported by (ROOM) is the same before and after the loop.
Cheers, Edi. _______________________________________________ rdnzl-devel mailing list rdnzl-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/rdnzl-devel
participants (2)
-
Edi Weitz -
Matthew Lamari