xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hans Stoessel" <hstoes...@pm-medici.ch>
Subject Re: JSVGCanvas: java.lang.OutOfMemoryError
Date Thu, 17 Apr 2003 07:14:44 GMT
I try it with the memory monitor and the memory is increasing with every
using of JSVGCanvas. And I can't reach a solid baseline if I call the
carbage collector manially. I have a look to my code again and I don't think
there is a reference dangling. Could it be, that is a problem with the SVG
file? I can't imaging that, but I really don't know where I can find the
memory leak...

Thanks

Hans

"Thomas E Deweese" <thomas.deweese@kodak.com> schrieb im 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> ---------------------------------------------------------------------
> HS> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org For
> HS> 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