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] -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them, In the land of Redmond, where the Windows lie. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
