<div dir="ltr"><div><div><div>Hi Bruno,<br><br></div>The only thing that your code segment shows is a potential leak in your own management of MY_DATA_POINTER. This is down to your app, nothing we can do about that in the OSG community.<br><br></div>As for the memory tool suggesting a leak, well track it down, find out what the leak is.<br><br></div><div>Please realized the when working with OpenGL the OSG will creating OpenGL objects that will reside in the drivers memory, only once the GL objects are cleaned up will that memory be freed. Even if the OSG tells the OpenGL drive to free these objects the driver may well do this in a lazy fashion. The OSG also keeps track of OpenGL object ID's that are to be deleted in thread safe caches so that the GL objects (like texture objects) can be later deleted by a graphics thread, rather than the thread that the OSG was deleted from. This approach is required as OSG apps can multiple threads running with different objects being deleted in different threads, in the case of OpenGL calls they can only be done from threads with the appropriate graphics context current.<br> <br></div><div>There is no way for us to know what is going wrong, if anything, in your application. You have you application, your data, you usage model, you drivers, your hardware, your debuggers and memory tools, your are the one with all the tools to hand to determine what the problem is. All we can do is provide general pointers.<br></div><div><br></div>Robert.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 13 April 2016 at 11:31, Bruno Oliveira <span dir="ltr"><<a href="mailto:bruno.manata.oliveira@gmail.com" target="_blank">bruno.manata.oliveira@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>What I am doing is checking under Linux system tool for the allocated memory, and I see that when I unload my textures, the system still identifies that my app is occupying some memory. <br><br></div><div>Please notice I have no memory leak! If I setup another image to display instead of the current one, the memory will be deallocated and reallocated to the new image size (for instance, if I first have 600mb image in display and then I delete it and create a 10mb image, I only get 10mb ram occupied)<br></div><div><br></div>What I have in my own storage is a raw image data pointer, and I manage that memory. I am almost sure my code is not leak. But check my code:<br><br><br> osg::ref_ptr<osg::Image> image = new osg::Image();<br> //image->setPixelBufferObject(new osg::PixelBufferObject(image.get()));<span class=""><br><br><br><br> image->setImage(src->tileSize(), src->tileSize(),1,<br> GL_RGBA8,<br> GL_RGBA,<br> GL_UNSIGNED_INT_8_8_8_8_REV,<br></span></div><div> MY_DATA_POINTER,<br></div><div> osg::Image::NO_DELETE);<span class=""><br><br><br> // Setup texture<br> osg::ref_ptr<osg::Texture2D> texture = new osg::Texture2D;<br></span> texture->setImage(image);<br><br></div><b>If I comment out the image->setImage() and texture->setImage() lines, the problem disappears! That's why I suspect that OSG is keeping some internal buffers.</b><br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2016-04-13 9:44 GMT+01:00 Robert Osfield <span dir="ltr"><<a href="mailto:robert.osfield@gmail.com" target="_blank">robert.osfield@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>Hi Bruno,<br><br></div>The OSG is capable of robustly handling the memory of all objects that it handles. In your case you've disabled this with the NO_DELETE option will leaves the responsibility to your application to manage the lifetime of the data. It may be that you are doing this correctly, but perhaps there the bug is there.<br><br></div>In the OSG for most objects you don't explicitly delete objects you unreferenced them and they automatically get deleted if their reference count goes to zero. Use of ref_ptr<> is the best way to manage the reference counting for you. So you very rarely explicitly delete anything, and you certainly wouldn't explicitly delete a node in the scene graph - the destructor is hidden in protected to avoid you doing this as all scene graph objects are meant to be ref counted.<br><br></div>As for you own application, there isn't much we as third parties without the code in front of us can say about the exactly problem in your application. You should be wary of how you determining a leak, for instance under Windows the VisualStudio memory leak tool can produce false positive in certain circumstances. <br><span><font color="#888888"><br></font></span></div><span><font color="#888888">Robert.<br></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 13 April 2016 at 09:30, Bruno Oliveira <span dir="ltr"><<a href="mailto:bruno.manata.oliveira@gmail.com" target="_blank">bruno.manata.oliveira@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>OK, I understand that. I do that because I own the data pointer I'm sending, and I am totally sure I am freeing it. However, some other copy remains anywhere, and I don't have access to it.<br><br></div>If I delete the osg::Group where I am attaching images and re-add the same imgaes, no more memory is allocated, so it is using the same buffers somehow, but I can't force it to free the memory when I want to<br></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2016-04-13 7:21 GMT+01:00 Sebastian Messerschmidt <span dir="ltr"><<a href="mailto:sebastian.messerschmidt@gmx.de" target="_blank">sebastian.messerschmidt@gmx.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Hi Bruno,<br>
</div><span>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>Hello, <br>
<br>
</div>
I am creating an image from custom data pointer as follows,
however, this does not result in freeing my memory after I
delete the node and texture. How could this be?<br>
<br>
image->setImage(src->tileSize(), src->tileSize(),1,<br>
GL_RGBA8,<br>
GL_RGBA,<br>
GL_UNSIGNED_INT_8_8_8_8_REV,<br>
src->tileGridCoords(col,
row).m_data.data(),<br>
osg::Image::NO_DELETE);<br>
</div>
</div>
</blockquote></span>
You are telling OSG that you handle the memory yourself by stating
NO_DELETE.<br>
So basically you're responsible to delete it. <br>
<br>
Cheers<br>
Sebastian <br>
<blockquote type="cite"><span>
<div dir="ltr">
<div><br>
// Setup texture<br>
osg::ref_ptr<osg::Texture2D> texture = new
osg::Texture2D;<br>
texture->setImage(image.get());<br>
<br>
// Avoid background border between tiles<br>
// <a href="http://stackoverflow.com/questions/19611745/opengl-black-lines-in-between-tiles" target="_blank">http://stackoverflow.com/questions/19611745/opengl-black-lines-in-between-tiles</a><br>
texture->setWrap(osg::Texture::WRAP_S,
osg::Texture::CLAMP_TO_EDGE);<br>
texture->setWrap(osg::Texture::WRAP_T,
osg::Texture::CLAMP_TO_EDGE);<br>
<br>
texture->setInternalFormatMode(osg::Texture2D::USE_S3TC_DXT1_COMPRESSION);<br>
texture->setUnRefImageDataAfterApply( </div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
</span><pre>_______________________________________________
osg-users mailing list
<a href="mailto:osg-users@lists.openscenegraph.org" target="_blank">osg-users@lists.openscenegraph.org</a>
<a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a>
</pre>
</blockquote>
<br>
</div>
<br>_______________________________________________<br>
osg-users mailing list<br>
<a href="mailto:osg-users@lists.openscenegraph.org" target="_blank">osg-users@lists.openscenegraph.org</a><br>
<a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" rel="noreferrer" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
osg-users mailing list<br>
<a href="mailto:osg-users@lists.openscenegraph.org" target="_blank">osg-users@lists.openscenegraph.org</a><br>
<a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" rel="noreferrer" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
osg-users mailing list<br>
<a href="mailto:osg-users@lists.openscenegraph.org" target="_blank">osg-users@lists.openscenegraph.org</a><br>
<a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" rel="noreferrer" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
osg-users mailing list<br>
<a href="mailto:osg-users@lists.openscenegraph.org">osg-users@lists.openscenegraph.org</a><br>
<a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" rel="noreferrer" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
<br></blockquote></div><br></div>