native memory leak checking

Has anyone done memory leak checking for the native code in JOGL?

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.

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, but I have a leak report.

Is there a good way to explore and report those?

thanks
andy

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
>

I'm hoping to reproduce in a simpler app so I'd have a more helpful report, but I'll send what stacks I do have if I can't get something simpler, after another pass to make sure I've understood the lifecycle as much as I can.

Is there a way to build the native files for debugging?  A define for ant, I guess?

thanks
andy

On 10/26/2012 10:48 PM, Andy Skinner [via jogamp] wrote:
> I'm hoping to reproduce in a simpler app so I'd have a more helpful report,
> but I'll send what stacks I do have if I can't get something simpler, after
> another pass to make sure I've understood the lifecycle as much as I can.
>
Thank you.

> Is there a way to build the native files for debugging?  A define for ant, I
> guess?

-Dc.compiler.debug=true

~Sven