xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas E Deweese <thomas.dewe...@kodak.com>
Subject RE: JSVGCanvas: java.lang.OutOfMemoryError
Date Tue, 22 Apr 2003 19:41:58 GMT
>>>>> "BR" == Baron, Randy {PRG~Basel} <RANDY.BARON@Roche.COM> writes:

BR> I am also trying to track down a memory leak (that is making the
BR> application I'm working on unusable) and was wondering what was
BR> meant by "It is possible that your document has something that
BR> triggers a large memory leak (i.e. holding a reference to the
BR> document)."  What kind of thing can be in the SVG that could reach
BR> out into the java part and hold references?

    I would view it differently what thing in SVG could cause the java
part to hold references?  The answer is potentially lots of things
these would all represent bugs but you can imagine extra tracking
needs to be done for things like viewports, gradients, patterns,
filters, text etc.  

    So in general I would consider it possible that using script to
modify some of these things might leave behind a listener or
something.  Due to the way DOM is constructed if you hold a reference
to one node in the DOM tree the whole DOM tree (and anything attached
to it through listeners for example) sticks around.

    Does this make it clearer how 'straight' SVG might trigger large
memory leaks?

BR> -Randy

BR> -----Original Message----- From: Thomas E Deweese
BR> [mailto:thomas.deweese@kodak.com] Sent: Monday, April 21, 2003
BR> 2:16 PM To: Batik Users Subject: Re: JSVGCanvas:
BR> java.lang.OutOfMemoryError

>>>>> "HS" == Hans Stoessel <hstoessel@pm-medici.ch> writes:

HS> I try it with the memory monitor and the memory is increasing with
HS> every using of JSVGCanvas. And I can't reach a solid baseline if I
HS> call the carbage collector manially. I have a look to my code
HS> again and I don't think there is a reference dangling. Could it
HS> be, that is a problem with the SVG file? I can't imaging that, but
HS> I really don't know where I can find the memory leak...

BR>     Can you reproduce the memory leak by loading your SVG directly
BR> in Squiggle?  If so then send us the file (offline if large or you
BR> don't want the world to see it).  It is possible that your
BR> document has something that triggers a large memory leak
BR> (i.e. holding a reference to the document).

BR>     If you can't reproduce it this way then I still strongly
BR> suspect your code :) Try creating a small app that just pops up
BR> your dialog again and again.  Get a real Java heap tool.

HS> Thanks

HS> Hans

HS> "Thomas E Deweese" <thomas.deweese@kodak.com> schrieb im
HS> Newsbeitrag news:16020.12887.411199.423737@frog.rl.kodak.com...
>>> >>>>> "HS" == Hans Stoessel <hstoessel@pm-medici.ch> writes:
>>> 
HS> I think its definitely a bug in JSVGCanvas. You can reproduce it
HS> with the application batik-squiggle who uses JSVGCanvas to display
HS> SVG files. If you open a SVG file in it and reload this file a few
HS> times, you see in the task manager of Windows 2000 how the memory
HS> is increasing...
>>> Squiggle has a built in Memory monitor (with a GC button). When I
>>> use that with say samples/mapSpain.svg I can load it dozens of
>>> times and if I press collect two/three times the memory quickly
>>> returns to a solid baseline.  This is even true for 3d.svg
>>> (dyanmic document) - it actually has a lower baseline since we
>>> cache lots of image data for static documents.
>>> 
>>> We do not sprinkle our code with calls to the GC so naturally our
>>> heap grows until the JVM starts running out of space and _it_
>>> decides to do a GC for us.  This is why you see it's partition
>>> growing.  I suggest you use the monitor to do your checking.
>>> 
>>> I even tried cycling through several JSVGViewerFrames to see if
>>> old documents were hanging around and as far as I could tell they
>>> weren't.
>>> 
HS> Has nobody the same experience like me with JSVGCanvas?  Is there
HS> a workaround?
>>> I certainly haven't heard about it on the list.  I still think the
>>> problem is dangling references...
>>> 
HS> Thanks for any help.
>>>
HS> Hans
>>>
HS> "Thomas E Deweese" <thomas.deweese@kodak.com> schrieb im
HS> Newsbeitrag news:16020.817.728658.44321@frog.rl.kodak.com...
>>> >> >>>>> "HS" == Hans Stoessel <hstoessel@pm-medici.ch>
writes:
>>> >>
HS> Hi I use the following source code to display a svg file with a
HS> chart in a dialog:
>>> >> You are only showing the init code.  Since you create a new >>
>>> JSVGCanvas each time, I suspect that you are somehow holding on to
>>> >> a reference to the JSVGCanvas (or the dialog) somewhere in your
>>> >> code (often this can be hidden in a listener or something).
>>> >>
>>> >> While I can't rule out memory leaks in Batik (in fact I'd be >>
>>> surprised if there weren't at least a few) I don't think there are
>>> >> _gross_ memory leaks (I often view >100 SVG files in squiggle
>>> w/o a >> problem).
>>> >>
HS> If I do that a few times, then I have the java error:
HS> java.lang.OutOfMemoryError <<no stack trace available>>
>>> >>
HS> I use Batik 1.5 Beta 5 and Windows 2000. If I have a look in the
HS> task manager of windows, I see that the memory is increasing with
HS> every time I display a SVG file in my dialog.
>>> >>
HS> What could be wrong?
>>> >>
HS> Thanks for help
>>>
HS>
BR> ---------------------------------------------------------------------
HS> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org For
HS> additional commands, e-mail: batik-users-help@xml.apache.org




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




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


BR> ---------------------------------------------------------------------
BR> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org For
BR> 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


Mime
View raw message