1) Use jmap to generate a memory dump of the application (jmap
-dump:file=heap.bin).
2) Use the Eclipse Memory Analysis Tool (http://www.eclipse.org/mat/)
to load up the heap dump.
3) Find the offending object that' still sticking around when you
don't want it to.
4) Find the shortest path to the GC Root to figure out the chain of
references that is keeping the object in scope.
It'd be great if you could try that on your own application. However,
if that's a bit too much, I could try to reproduce your situation.
I'd need more details on how you are using the library, ideally with
some code snippets if you have them.
Thanks,
Brian
> --
> You received this message because you are subscribed to the Google Groups "OneBusAway API" group.
> To post to this group, send email to onebusa...@googlegroups.com.
> To unsubscribe from this group, send email to onebusaway-ap...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/onebusaway-api?hl=en.
>
I just got around to look at your code. In the ControllertPanel
class, is there a reason you create the GtfsReader as a member
variable instead of as a local variable inside of the initListener()
method. If you made it a local, it would go out of scope at the end
of the reader try { } block, freeing any internal memory stored
within.
Brian