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 George Armhold <ar...@cs.rutgers.edu> on 2002/09/19 18:02:43 UTC
apparent memory leak in JSVGComponent [Batik 1.5b4]
Hi,
I'm experiencing a similar problem to the one that James mentioned
back in August, but I'm using Batik 1.5b4. In my case, I'm using a
JSVGComponent and asking it to successively load different SVG
documents by calling setSVGDocument(). Windows Task Manager shows the
memory going up and up with each successive document, until finally I
get an OutOfMemoryException. I can provide a sample program that
tickles it, if needed. Can anyone suggest a fix or workaround?
Thanks
> Subject: Memory Leak in Batik1.5b3?
> From: James McArthur <ja...@pcorp.com.au>
> Date: 28 Aug 2002 08:26:30 +0930
> To: batik-users@xml.apache.org
>
> Hi,
>
> I think I may have found a leak in Batik 1.5b3 on
> Linux 2.4.18-3 #1 Thu Apr 18 07:32:41 EDT 2002 i686 unknown with the SUN
> Java VM 1.3.1.
>
> When I load and display an SVG onto a JSVGCanvas/JSVGComponent with the
> ALWAYS_DYNAMIC attribute set, I eventually end up with an
> OutOfMemoryException being thrown after doing a certain number of
> updates. The updates involve changing texts, shapes and colours of the
> SVG, setting them visible and invisible etc.
>
> I have attached a sample program that can duplicate this problem; albeit
> very slowly. In a larger program that I've written based on the same
> code, the leak takes about 12hours to wipe out the whole 64MB the JVM
> allocates by default for itself.
> The sample program will simply draw eight SVGs onto a JSVGCanvas, then
> update their colours and texts. Moving the window that contains the
> JSVGCanvas also helps to eat memory..
>
> I managed to decrease the time need to cause the OutOfMemoryException by
> running the sample program with the commands;
> java -Xmx16m -Xincgc ApplMain time.svg
>
>
> Hopefully, someone will look at the code and tell me that I'm doing
> something stupid :)
>
>
> James
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: apparent memory leak in JSVGComponent [Batik 1.5b4]
Posted by George Armhold <ar...@cs.rutgers.edu>.
James,
Seems like it's just you and me. :-) I found a workaround, which is
to call loadSVGDocument() rather than setSVGDocument(). This
apparently does not cause the leak.
James McArthur wrote:
> Hi,
>
> I was beginning to think I was the only one with the problem here :)
>
> I have tested the same code that I posted earlier with 1.5b3 and 1.5b4b
> and the problem is still there...
>
> James
>
> On Fri, 2002-09-20 at 01:32, George Armhold wrote:
>
>>Hi,
>>
>>I'm experiencing a similar problem to the one that James mentioned
>>back in August, but I'm using Batik 1.5b4. In my case, I'm using a
>>JSVGComponent and asking it to successively load different SVG
>>documents by calling setSVGDocument(). Windows Task Manager shows the
>>memory going up and up with each successive document, until finally I
>>get an OutOfMemoryException. I can provide a sample program that
>>tickles it, if needed. Can anyone suggest a fix or workaround?
>>
>>Thanks
--
George Armhold
Rutgers University
eLearning Grant, DCIS
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: apparent memory leak in JSVGComponent [Batik 1.5b4]
Posted by James McArthur <ja...@pcorp.com.au>.
Hi,
I was beginning to think I was the only one with the problem here :)
I have tested the same code that I posted earlier with 1.5b3 and 1.5b4b
and the problem is still there...
James
On Fri, 2002-09-20 at 01:32, George Armhold wrote:
> Hi,
>
> I'm experiencing a similar problem to the one that James mentioned
> back in August, but I'm using Batik 1.5b4. In my case, I'm using a
> JSVGComponent and asking it to successively load different SVG
> documents by calling setSVGDocument(). Windows Task Manager shows the
> memory going up and up with each successive document, until finally I
> get an OutOfMemoryException. I can provide a sample program that
> tickles it, if needed. Can anyone suggest a fix or workaround?
>
> Thanks
>
>
> > Subject: Memory Leak in Batik1.5b3?
> > From: James McArthur <ja...@pcorp.com.au>
> > Date: 28 Aug 2002 08:26:30 +0930
> > To: batik-users@xml.apache.org
> >
> > Hi,
> >
> > I think I may have found a leak in Batik 1.5b3 on
> > Linux 2.4.18-3 #1 Thu Apr 18 07:32:41 EDT 2002 i686 unknown with the SUN
> > Java VM 1.3.1.
> >
> > When I load and display an SVG onto a JSVGCanvas/JSVGComponent with the
> > ALWAYS_DYNAMIC attribute set, I eventually end up with an
> > OutOfMemoryException being thrown after doing a certain number of
> > updates. The updates involve changing texts, shapes and colours of the
> > SVG, setting them visible and invisible etc.
> >
> > I have attached a sample program that can duplicate this problem; albeit
> > very slowly. In a larger program that I've written based on the same
> > code, the leak takes about 12hours to wipe out the whole 64MB the JVM
> > allocates by default for itself.
> > The sample program will simply draw eight SVGs onto a JSVGCanvas, then
> > update their colours and texts. Moving the window that contains the
> > JSVGCanvas also helps to eat memory..
> >
> > I managed to decrease the time need to cause the OutOfMemoryException by
> > running the sample program with the commands;
> > java -Xmx16m -Xincgc ApplMain time.svg
> >
> >
> > Hopefully, someone will look at the code and tell me that I'm doing
> > something stupid :)
> >
> >
> > James
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
>
>