JOGL-current application consumes more and more memory

Hello Jogl list,

we are currently writing a JAVA/JoGL application using the following JOGL version:

http://jogamp.org/deployment/jogamp-current/jogl-all-awt.jnlp to deploy

the application starts fine but after a while the process starts eating-up memory up to 2Gbytes (we are estimating the application should consume in the order of 200MBytes total)

We have tried to use the classic JAVA tools to profile memory usage but they do not report memory objects explaining 2GB of RAM.

The problem is present on very different setups (linux 64 + nvidia, windows 64bits + basic sandybridge laptop....). How can we debug memory allocations in the JNI side ? Any other suggestion appreciated.

On Monday, October 24, 2011 02:56:05 PM seb [via jogamp] wrote:
Thank you for your post + findings so far.

Please validate against:
  http://jogamp.org/deployment/archive/master/gluegen_424-joal_228-jogl_526-jocl_455/archive/

I have profiled NEWT apps on desktop and mobile/Android and cannot confirm
a heap leak in our current codebase. On the contrary, I was able to reduce
a few leaks while working on the Android port.

Since we cannot talk about a phenomenom we don't experience,
it would be best if your can provide a most small test application,
best a unit test, to us.
Then we are able to help profiling and finding the culprit.

Another very essential information is to know the exact platform[s]
on which you are experiencing this heap utilizations.

Please follow the FAQ 'Bugreports & Testing' thoroughly
  http://jogamp.org/wiki/index.php/Jogl_FAQ#Bugreports_.26_Testing

What would be nice to have is:
  http://jogamp.org/wiki/index.php/Jogl_FAQ#Runtime_Version_Check


~Sven

Hi

GLJPanel is quite memory intensive, there is another leak when using GLCanvas with autoSwapBufferMode set to false if and only if you don't call swapBuffers() for a long time. I reduced the memory usage of TextRenderer by adding a glyph cache. Do you reproduce such leaks on the demos?

thank you for your quick reply,

I will try to run my application against the suggested build first and report the result here.

my question was more whether there is anything to do to convince myself that the bug is on our side (we have spent the last 10 days auditing our code (relatively small i.e. 2000 lines but part of a much much bigger application we do not control) and doing all sorts of checks.

Is there anything we can do to trace memory allocations from the native code ? Ideally I would love a trace of all mallocs done by the JNI component ? I was looking for a way to LD_PRELOAD a malloc library but I do not want to see the mallocs of the JVM ? I guess I could recompile jogl to do this but I was wondering whether anything like this is already done ?

thanks we are indeed using autoSwapBufferMode set to false, so we will temporarily change this and let you know whether this changes anything.

we did not try the demos yet.

Hi

Do you use GLCanvas, GLJPanel or GLWindow? I wrote a bug report about that problem:
https://jogamp.org/bugzilla/show_bug.cgi?id=455

oh yes we do use them,

thank you for the bug report,

for now we are currently rebuilding a new workstation from scratch (hardware and software) to make sure our setup is 100% clean

We just added jogl version dump like suggested by Sven so that we are 100% sure of what we are testing and can correctly report what exactly we have.