You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Thomas DeWeese <Th...@Kodak.com> on 2005/01/03 12:02:34 UTC
Re: Batik memory leak
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 <Th...@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 <Th...@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
Re: Batik memory leak
Posted by "G. Wade Johnson" <gw...@anomaly.org>.
Terrific!
I'll download it tonight.
Thanks,
G. Wade
On Mon, 03 Jan 2005 06:02:34 -0500
Thomas DeWeese <Th...@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 <Th...@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 <Th...@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