Detecting memory leaks

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Detecting memory leaks

PJDM
I have a working JOGL application. However, using GPU-Z I can see the GPU memory used going up. This could be caused by not matching GenBuffers with DeleteBuffers, for instance.

Poking around in the JOGL source, something like GLObjectTracker looks like it could be useful. Is there a way of telling JOGL to dump what GL objects it thinks are live so I can figure out if I'm leaking memory/names/buffers/etc?

Thanks.

PJDM
Reply | Threaded
Open this post in threaded view
|

Re: Detecting memory leaks

gouessej
Administrator
Hi

Have you set jogl.debug.GLBufferObjectTracker to true?
https://github.com/sgothel/jogl/blob/master/src/jogl/classes/jogamp/opengl/GLBufferObjectTracker.java

I have already solved a similar problem in my game, I can give you some very detailed advises to do the same in your application. My aim was to avoid problems of high memory footprint and memory leaks, especially when my game runs for a long time. I had to take care of 2 "aspects", the OpenGL resources and the resources on the native heap, both had to be manually monitored, you can't just expect Java from doing it smartly. GPU-Z only shows you one part of the problem. In my humble opinion, you should use an high level mechanism allowing you to "mark" a VBO as good candidate for the trash bin, your responsibility would consist in using this mechanism when you can know that you no loner need a model. In JFPSM, I know that I no longer need a model when the end user closes a tab and there is no remaining viewer showing it.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: Detecting memory leaks

PJDM
Yes, I've tried setting jogl.debug.GLBufferObjectTracker and jogl.debug.GLStatusTracker but nothing appears on stderr. Defining jogl.debug.TraceGL does produce a lot of output.

Curiously, setting jogl.verbose displays:
JOGL specification version null
JOGL implementation version null
JOGL implementation vendor null

(using 2.1.3-rc-20131212, I'm not able to use 2.1.4).

I create and delete buffers on the fly. Sometimes I might miss deleting a buffer, so that buffer leaks. Rather than scanning through the debug output, I'd like JOGL to tell me what buffers are in use. Given that JOGL seems to be tracking that information, I prefer not to have to write the code to do my own tracking as well. I want to know when I've missed candidates for the bin.

PJDM
Reply | Threaded
Open this post in threaded view
|

Re: Detecting memory leaks

gouessej
Administrator
What's wrong with JOGL 2.1.4? We provide support only for the very latest version. If you have found a regression, please let us know.

I'm not sure that it was possible to use a public API to get this kind of information in JOGL 2.1.3, I only look at the latest version. Your version doesn't contain the fix for the bug 984 affecting this tracker. Look at TestMapBufferRead01NEWT to see how to use this feature.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: Detecting memory leaks

elect
Don't you have a global arraylist/hashmap where you keep all your rendering objects?
Reply | Threaded
Open this post in threaded view
|

Re: Detecting memory leaks

Sven Gothel
Administrator
In reply to this post by PJDM
On 03/05/2014 01:14 PM, PJDM [via jogamp] wrote:
> I create and delete buffers on the fly. Sometimes I might miss deleting a
> buffer, so that buffer leaks. Rather than scanning through the debug output,
> I'd like JOGL to tell me what buffers are in use. Given that JOGL seems to be
> tracking that information, I prefer not to have to write the code to do my own
> tracking as well. I want to know when I've missed candidates for the bin.

Pls file a bug report 'enhancement'.

Yes, we can provide this information.

~Sven



signature.asc (894 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Detecting memory leaks

PJDM
Sven: https://jogamp.org/bugzilla/show_bug.cgi?id=993. Thanks.

elect: so you're saying that if I kept track all of my rendering objects, I wouldn't have to keep track all of my rendering objects. :-)

Julien: bug 984 is what's wrong with v2.1.4. I found a regression and let you know. :-)

Looking at TestMapBufferRead01NEWT, I'm not sure how GLBufferStorage helps (if that's what you're directing me to). I'm not looking for information on a particular buffer, I'm trying to discover what buffers are leaking. Having JOGL being able to dump it's current tracked buffer state would be enormously helpful.

Enabling jogl.debug.TraceGL doesn't help. Example output:

glGenBuffers(<int> 0x1, <[I>, <int> 0x0)
glBindBuffer(<int> 0x8892, <int> 0x1)
glDeleteBuffers(<int> 0x1, <[I>, <int> 0x0)

Although these are (presumably) all on the same buffer, I can't tell the names returned by glGenBuffers(), and I can't tell the names being passed to glDeleteBuffers(), so I can't parse the trace output and spot mismatches where I'm deleting the wrong buffer, or not deleting a buffer at all. Another enhancement request?

PJDM
Reply | Threaded
Open this post in threaded view
|

Re: Detecting memory leaks

elect
PJDM wrote
elect: so you're saying that if I kept track all of my rendering objects, I wouldn't have to keep track all of my rendering objects. :-)
^^

Just asking

However, I have a status variable for each of my mesh (rendering objects)

public enum Status {

        uninitialized,
        toInitialize,
        initialized,
        toDelete;
    }

And at every display a routine will init (vbo/vao) or delete (vbo/vao) any object that needs to
Reply | Threaded
Open this post in threaded view
|

Re: Detecting memory leaks

Sven Gothel
Administrator