Hi G. Wade,
Please check out current CVS. I could run your example for several hours w/o a problem with the new code.
G. Wade Johnson wrote:
Hi Thomas,
Thanks for getting back to this.
On Thu, 16 Dec 2004 08:02:57 -0500 Thomas DeWeese <[EMAIL PROTECTED]> wrote:
Hi G. Wade,
You might check out current CVS. I put in a fix for a memory leak relating to twiddling the xlink:href on an image element. I'll mention that I don't think this is your memory leak because it took a _lot_ more twiddles than 100 to run Java out of memory, but with this fix I was able to alternate between two image refs all night without any heap growth.
I tried the latest CVS and the results have changed. It now takes between 354 and 367 images to generate the out of memory condition.
Are you loading 100 different images?
My application attempts to walk through 482 separate images. Each image is a straight-forward histogram of some data I was working on.
Anyway if it fixes the problem let me know, and if it doesn't fix the problem for you a test case would be nice. Even if you don't have time for a test case right now, creating a bugzilla that captures the details you do know might be helpful.
I'll see if I can get something into bugzilla this weekend. I just hate reporting a bug without a clean, reproducable test case, preferably a small one.
G. Wade
G. Wade Johnson wrote:
If it helps, I've seen the same behavior in an image viewer type of SVG I wrote. I'm just displaying it in Squiggle and loading different images by changing the xlink:href in an <image/> element.
The amount of memory consumed continues to grow the more images I display. (Each time I am replacing the xlink:href value, and I keep no references to the images anywhere.)
It takes over 100 images to reach the out of memory case, but it always happens. I hadn't posted anything, because I haven't had time to track it down.
I've seen the same behavior on Batik 1.5 and 1.5.1.
G. Wade
On Mon, 13 Dec 2004 21:42:18 -0500 Thomas DeWeese <[EMAIL PROTECTED]> wrote:
Archie Cobbs wrote:
Note that one thing my application does is change the "xlink:href" attribute on existing <use> nodes to point them at different
symbols.>
Perhaps there is some leak where Batik retains a reference to the previously pointed-to <use> referent?
Aha! I changed my code to delete the previous <use> and add a new <use> each time, instead of just changing the "xlink:href" attribute, and this fixed the leak.
So as far as I can tell there is a Batik memory leak in handling this case.
What version of Batik are you using?
Also are the href references local, "#blah", or external, "foo.svg#bar"? A mix?
I've given the code a good looking over and it is hard for me to see where the leak occurs, but I am very interested in finding
it.>Any chance of a reproducible test case?
-------------------------------------------------------------------
-->To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
