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 Archie Cobbs <ar...@dellroad.org> on 2004/12/13 21:03:10 UTC
Batik memory leak
There was a post recently about long running Batik applications
running out of memory. I've experienced this problem too. Here is
my current theory about what's going on, at least in my case..
Our application animates an SVG document by adding and removing
nodes, and also by modifying node attributes. A mouse listener
is alwyas added to newly added nodes - and the same listener object
is added every time.
I've checked that we are removing the nodes that we add, so that
we're not just growing the document itself.
The objects that accumulate in my heap are never-freed are instances
of BridgeContext$EventListenerMemento. These instances remain in the
BridgeContext instance field "eventListenerSet", causing this set to
grow in size until memory is exhausted. In our application, this takes
a couple of days to occur.
The EventListenerMemento objects contain two SoftReference. When either
reference is cleared, the EventListenerMemento is removed from
"eventListenerSet". Of course this can only happen when there are no
strong references to the soft-referenced object.
One SoftReference points into the DOM and the other points to the Listener.
Clearly, live DOM objects are always going to be referenced.
As for the Listener, suppose the application uses the same Listener
object over and over again. Then any EventListenerMemento objects that
reference that Listener will never be cleared either.
The result is that the EventListenerMemento object accumulate
without bound.
When I load a completely new document, the EventListenerMemento objects
are all freed as expected because the old DOM is no longer referenced.
As a workaround I tried to instantiating a new Listener object for
each registration instead of re-using the same one. This helped
(I think?) however, there is still a major memory leak of the
EventListenerMemento objects.
I'm not sure what the right way to fix this would be. In any case it
seems like the Memento class has a design flaw. But also I don't understand
why my workaround didn't fix the problem... i.e., perhaps there is some
code that is calling BridgeContext.storeEventListener() that shouldn't be.
There are only 24 instances in Batik where BridgeContext.storeEventListener()
is invoked.. perhaps one or more of these is inappropriate?
Any help or insights greatly appreciated.
Thanks,
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
*
Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
*
---------------------------------------------------------------------
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 Jamie Browning <ja...@exponent.co.uk>.
Thomas DeWeese wrote:
> Hi Archie,
>
> I believe the problem is now fixed in CVS. My test application
> ran overnight (twiddling the href 20-30 times a sec) with no
> detectable increase in the baseline heap size (this is
> ~1million twiddles so the heap would have grown significantly
> even if a single object was leaked).
>
> Archie Cobbs wrote:
>
>> Thomas DeWeese wrote:
>>
>>>>> 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?
>>>>
>>>>
>>>> I'll try to come up with one as soon as time permits... hopefully
>>>> it won't be too hard.
>>>
>>>
>>> Your off the hook I have one. I didn't think I was getting
>>> anywhere but I ran my test overnight and it failed. I also think
>>> I have a fix, I'll need to run the test overnight again however.
>>
>>
>> Great! Thanks for working on this problem.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
>
>
>
All power to Open Source! Less than 72 hours from initial post to fix -
Thomas, you're a star!
---------------------------------------------------------------------
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 Archie Cobbs <ar...@dellroad.org>.
Thomas DeWeese wrote:
> I believe the problem is now fixed in CVS. My test application
> ran overnight (twiddling the href 20-30 times a sec) with no
> detectable increase in the baseline heap size (this is
> ~1million twiddles so the heap would have grown significantly
> even if a single object was leaked).
Thanks Thomas!
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
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 Thomas DeWeese <Th...@Kodak.com>.
Hi Archie,
I believe the problem is now fixed in CVS. My test application
ran overnight (twiddling the href 20-30 times a sec) with no
detectable increase in the baseline heap size (this is
~1million twiddles so the heap would have grown significantly
even if a single object was leaked).
Archie Cobbs wrote:
> Thomas DeWeese wrote:
>
>>>> 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?
>>>
>>> I'll try to come up with one as soon as time permits... hopefully
>>> it won't be too hard.
>>
>> Your off the hook I have one. I didn't think I was getting
>> anywhere but I ran my test overnight and it failed. I also think
>> I have a fix, I'll need to run the test overnight again however.
>
> Great! Thanks for working on this problem.
---------------------------------------------------------------------
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 Archie Cobbs <ar...@dellroad.org>.
Thomas DeWeese wrote:
>>> 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?
>>
>> I'll try to come up with one as soon as time permits... hopefully
>> it won't be too hard.
>
> Your off the hook I have one. I didn't think I was getting
> anywhere but I ran my test overnight and it failed. I also think
> I have a fix, I'll need to run the test overnight again however.
Great! Thanks for working on this problem.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
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 Thomas DeWeese <Th...@Kodak.com>.
Hi Archie,
Archie Cobbs wrote:
>> 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?
>
> I'll try to come up with one as soon as time permits... hopefully
> it won't be too hard.
Your off the hook I have one. I didn't think I was getting
anywhere but I ran my test overnight and it failed. I also think
I have a fix, I'll need to run the test overnight again however.
The root of the problem is as you suspected the reuse of
a listener on elements that don't go to GC.
---------------------------------------------------------------------
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 Archie Cobbs <ar...@dellroad.org>.
Thomas DeWeese wrote:
> What version of Batik are you using?
1.5.1
> Also are the href references local, "#blah", or external,
> "foo.svg#bar"? A mix?
All are local references into the same document, e.g., "#foo".
> 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?
I'll try to come up with one as soon as time permits... hopefully
it won't be too hard.
Thanks,
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
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
Re: Batik memory leak
Posted by Thomas DeWeese <Th...@Kodak.com>.
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>.
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
--
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: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: Batik memory leak
Posted by Thomas DeWeese <Th...@Kodak.com>.
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.
Are you loading 100 different images?
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.
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
Re: Batik memory leak
Posted by "G. Wade Johnson" <gw...@anomaly.org>.
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
--
An expert is a person who has made all the mistakes that can be made in
a
very narrow field. -- Niels Bohr
---------------------------------------------------------------------
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 Thomas DeWeese <Th...@Kodak.com>.
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
Re: Batik memory leak
Posted by Archie Cobbs <ar...@dellroad.org>.
Archie Cobbs wrote:
>> Are you certain that the nodes you remove are going to GC?
>>I suspect they are not (this may be a Batik problem or it may
>>be a problem in your app). Note that this can't be a Memento
>>problem since it uses soft references.
>
> I picked a random memento and looked at what it was referencing.
> It pointed to a <g> node that is the rererent of a <use> node
> (i.e., the <g> node contained stuff that is in the <defs> section).
>
> 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.
Thanks,
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
*
Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
*
---------------------------------------------------------------------
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 Archie Cobbs <ar...@dellroad.org>.
Thomas DeWeese wrote:
>> Our application animates an SVG document by adding and removing
>> nodes, and also by modifying node attributes. A mouse listener
>> is alwyas added to newly added nodes - and the same listener object
>> is added every time.
>
> But this listener is your listener not a "bridge context listener".
> I hope you aren't registering it with the BridgeContext are you?
No.. you are right, this "reused listener" thing is a red herring.
I didn't realize the listeners were different.
>> I've checked that we are removing the nodes that we add, so that
>> we're not just growing the document itself.
>
> Are you certain that the nodes you remove are going to GC?
> I suspect they are not (this may be a Batik problem or it may
> be a problem in your app). Note that this can't be a Memento
> problem since it uses soft references.
I picked a random memento and looked at what it was referencing.
It pointed to a <g> node that is the rererent of a <use> node
(i.e., the <g> node contained stuff that is in the <defs> section).
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?
My application holds a reference to the <use> node of course, but
it never references the referent of the <use> node (it lets Batik
figure that out via the "xlink:href" attribute). So I know for certain
that I'm not holding a direct reference to the referent of the <use>.
E.g., does Batik remove its reference to the previously-referred to
node when the "xlink:href" attribute changes?
>> The objects that accumulate in my heap are never-freed are instances
>> of BridgeContext$EventListenerMemento. These instances remain in the
>> BridgeContext instance field "eventListenerSet", causing this set to
>> grow in size until memory is exhausted. In our application, this takes
>> a couple of days to occur.
>
> What type of objects are you adding/removing? Text/use/image?
I'm adding mostly <use> references to pre-defined icons and text.
> But if you remove nodes from the DOM and keep no references from
> your code the 'old' nodes should go to GC and the memento should go
> away.
Agreed..
Thanks again for your help.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
*
Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
*
---------------------------------------------------------------------
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 Thomas DeWeese <Th...@Kodak.com>.
Hi Archie,
Archie Cobbs wrote:
> There was a post recently about long running Batik applications
> running out of memory. I've experienced this problem too. Here is
> my current theory about what's going on, at least in my case..
>
> Our application animates an SVG document by adding and removing
> nodes, and also by modifying node attributes. A mouse listener
> is alwyas added to newly added nodes - and the same listener object
> is added every time.
But this listener is your listener not a "bridge context listener".
I hope you aren't registering it with the BridgeContext are you?
> I've checked that we are removing the nodes that we add, so that
> we're not just growing the document itself.
Are you certain that the nodes you remove are going to GC?
I suspect they are not (this may be a Batik problem or it may
be a problem in your app). Note that this can't be a Memento
problem since it uses soft references.
> The objects that accumulate in my heap are never-freed are instances
> of BridgeContext$EventListenerMemento. These instances remain in the
> BridgeContext instance field "eventListenerSet", causing this set to
> grow in size until memory is exhausted. In our application, this takes
> a couple of days to occur.
What type of objects are you adding/removing? Text/use/image?
> One SoftReference points into the DOM and the other points to the Listener.
> Clearly, live DOM objects are always going to be referenced.
But if you remove nodes from the DOM and keep no references from
your code the 'old' nodes should go to GC and the memento should go
away.
> As for the Listener, suppose the application uses the same Listener
> object over and over again. Then any EventListenerMemento objects that
> reference that Listener will never be cleared either.
Except it isn't your listeners that are in the memento it's
Batik's listeners.
> When I load a completely new document, the EventListenerMemento objects
> are all freed as expected because the old DOM is no longer referenced.
This is because the whole reason for the existence of the
Memento is so Batik knows what listeners it needs to remove from
the document when the document becomes 'unattached' (i.e. when
BridgeContext.dispose() is called). Batik is careful to "cleanup
after it's self" so the resultant document is not "polluted".
> I'm not sure what the right way to fix this would be. In any case it
> seems like the Memento class has a design flaw. But also I don't understand
> why my workaround didn't fix the problem... i.e., perhaps there is some
> code that is calling BridgeContext.storeEventListener() that shouldn't be.
There may be a flaw but I don't think it's with the Memento class.
Someone is most likely keeping the old DOM nodes alive.
> There are only 24 instances in Batik where BridgeContext.storeEventListener()
> is invoked.. perhaps one or more of these is inappropriate?
>
> Any help or insights greatly appreciated.
I've done my best ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org