xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "G. Wade Johnson" <gwa...@anomaly.org>
Subject Re: Batik memory leak
Date Mon, 03 Jan 2005 12:36:08 GMT
Terrific!

I'll download it tonight.

Thanks,
G. Wade

On Mon, 03 Jan 2005 06:02:34 -0500
Thomas DeWeese <Thomas.DeWeese@Kodak.com> wrote:

> 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 <Thomas.DeWeese@Kodak.com> 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 <Thomas.DeWeese@Kodak.com> 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: batik-users-unsubscribe@xml.apache.org
> >>>
> >>>>For additional commands, e-mail: batik-users-help@xml.apache.org
> >>>
> >>>
> >>>
> >>
> >>-------------------------------------------------------------------
> >-->To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> >>For additional commands, e-mail: batik-users-help@xml.apache.org
> > 
> > 
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org


-- 
They made a very satisfying thump when they hit the floor.
                            -- G'Kar - "A Late Delivery from Avalon"

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org


Mime
View raw message