Login  Register

Re: native memory leak checking

Posted by Sven Gothel on Oct 26, 2012; 5:44pm
URL: https://forum.jogamp.org/native-memory-leak-checking-tp4026624p4026625.html

On 10/26/2012 07:14 PM, Andy Skinner [via jogamp] wrote:
> Has anyone done memory leak checking for the native code in JOGL?

Resource lifecycles ( NativeWindow(Device, Screen, Config), GL(Drawable,
Context) and NEWT ) are validated - even at runtime.
This can be very well observed if you miss to dispose something
at the end of your application on X11.

>
> I've got some memory leak reports, but they are in a rather large system, and
> I'd like to reproduce them in a small Java app.

If you find any, great - I doubt there are any left.

>
> I tried valgrind, but haven't yet gotten it to work.
>
> In JSR-231, there was a leak related to visuals.  It was mentioned in the
> comments in the code, and we just filtered the leak in our reports until it
> was fixed.  Now there is no longer a leak mentioned, in a similar but
> different place, and the code where I'm looking seems OK,

Yes, all X11/GLX visuals have been fixed in early JOGL2 days.

> but I have a leak
> report.

Then pls be so kind and open a bug report and share
your findings w/ us - very much appreciated.

>
> Is there a good way to explore and report those?

Depends on the nature of the leak.
X11 client/server leaks .. I don't know, we use application level
validation in some places, and the architecture tries to assure
sanity here.

Simple heap memory leaks, well .. I was using valgrind before
and binding some memory tool to a native executable.
Never tried this w/ Java though.

We know ofc that a simple rise of heap consumption
of a JVM instance is not necessarily a leak,
due to the nature of GC .. and other 'strategies' of the JVM.

~Sven

>
> thanks
> andy
>


signature.asc (907 bytes) Download Attachment