incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Weir (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ODFTOOLKIT-300) Memory Leak in ODF Simple API
Date Fri, 10 Feb 2012 17:24:59 GMT

    [ https://issues.apache.org/jira/browse/ODFTOOLKIT-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13205559#comment-13205559
] 

Rob Weir commented on ODFTOOLKIT-300:
-------------------------------------

The fact that the heap memory is constantly increasing does not prove there is a memory leak.
 That is because the JVM will normally defer garbage collection until it is running low on
heap space. 

The test you want to do, to prove a memory leak, is to set a low heap max size (-Xmx command
line flag) and then to run the test in a loop until you get a memory exception.  If you get
an OutOfMemoryException after many iterations of the loop, then that isa good indication you
have a memory leak.

Also, you could insert calls into the app to call System.gc() followed by Runtime.freeMemory()
to see if that is changing.  It is important to call gc(), so the JVM knows to garbage collect.
                
> Memory Leak in ODF Simple API
> -----------------------------
>
>                 Key: ODFTOOLKIT-300
>                 URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-300
>             Project: ODF Toolkit
>          Issue Type: Bug
>          Components: simple api
>    Affects Versions: 0.8.7
>         Environment: odfdom-java-0.8.7.jar; simple-odf-0.6.6.jar
>            Reporter: Mathias Silbermann
>            Assignee: Devin Han
>         Attachments: MemoryLeak_300.java, TestTextSelection.odt
>
>
> There is a memory leak in the ODF Simple API. I tried both, versions 0.6.6 and 0.6.5.
It appears when running code like the examples on cookbook page
> http://incubator.apache.org/odftoolkit/simple/document/cookbook/Manipulate%20TextSearch.html
> In short, the call TextNavigation.nextSelection() leads to the leak. When you look down
the method's call stack, you will find that items are added to the static variable "repository"
of the static inner class "Selection.SelectionManager". The added items are never removed
from the repository. One indication is that the method Selection.SelectionManager.unregisterItem()
is never called.
> The code works fine if text navigation is done with few documents. But when its run on
a server thousands of times, it will fill the JVMs memory.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message