I think this could be related to the driver. Because when I redo my scene, the memory is not actually leaked, it is rewritten
2016-04-13 11:55 GMT+01:00 Robert Osfield <[email protected]>: > Hi Bruno, > > 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. > > As for the memory tool suggesting a leak, well track it down, find out > what the leak is. > > 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. > > 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. > > Robert. > > On 13 April 2016 at 11:31, Bruno Oliveira <[email protected] > > wrote: > >> 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. >> >> 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) >> >> 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: >> >> >> osg::ref_ptr<osg::Image> image = new osg::Image(); >> //image->setPixelBufferObject(new >> osg::PixelBufferObject(image.get())); >> >> >> >> image->setImage(src->tileSize(), src->tileSize(),1, >> GL_RGBA8, >> GL_RGBA, >> GL_UNSIGNED_INT_8_8_8_8_REV, >> MY_DATA_POINTER, >> osg::Image::NO_DELETE); >> >> >> // Setup texture >> osg::ref_ptr<osg::Texture2D> texture = new osg::Texture2D; >> texture->setImage(image); >> >> *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.* >> >> 2016-04-13 9:44 GMT+01:00 Robert Osfield <[email protected]>: >> >>> Hi Bruno, >>> >>> 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. >>> >>> 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. >>> >>> 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. >>> >>> Robert. >>> >>> On 13 April 2016 at 09:30, Bruno Oliveira < >>> [email protected]> wrote: >>> >>>> 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. >>>> >>>> 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 >>>> >>>> 2016-04-13 7:21 GMT+01:00 Sebastian Messerschmidt < >>>> [email protected]>: >>>> >>>>> Hi Bruno, >>>>> >>>>> Hello, >>>>> >>>>> 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? >>>>> >>>>> image->setImage(src->tileSize(), src->tileSize(),1, >>>>> GL_RGBA8, >>>>> GL_RGBA, >>>>> GL_UNSIGNED_INT_8_8_8_8_REV, >>>>> src->tileGridCoords(col, >>>>> row).m_data.data(), >>>>> osg::Image::NO_DELETE); >>>>> >>>>> You are telling OSG that you handle the memory yourself by stating >>>>> NO_DELETE. >>>>> So basically you're responsible to delete it. >>>>> >>>>> Cheers >>>>> Sebastian >>>>> >>>>> >>>>> // Setup texture >>>>> osg::ref_ptr<osg::Texture2D> texture = new osg::Texture2D; >>>>> texture->setImage(image.get()); >>>>> >>>>> // Avoid background border between tiles >>>>> // >>>>> http://stackoverflow.com/questions/19611745/opengl-black-lines-in-between-tiles >>>>> texture->setWrap(osg::Texture::WRAP_S, >>>>> osg::Texture::CLAMP_TO_EDGE); >>>>> texture->setWrap(osg::Texture::WRAP_T, >>>>> osg::Texture::CLAMP_TO_EDGE); >>>>> >>>>> >>>>> texture->setInternalFormatMode(osg::Texture2D::USE_S3TC_DXT1_COMPRESSION); >>>>> texture->setUnRefImageDataAfterApply( >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> osg-users mailing >>>>> [email protected]http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> osg-users mailing list >>>>> [email protected] >>>>> >>>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> osg-users mailing list >>>> [email protected] >>>> >>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>>> >>>> >>> >>> _______________________________________________ >>> osg-users mailing list >>> [email protected] >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>> >>> >> >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
