[osg-users] image is not being freed
Robert Osfield
robert.osfield at gmail.com
Wed Apr 13 03:55:58 PDT 2016
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 <bruno.manata.oliveira at gmail.com>
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 <robert.osfield at gmail.com>:
>
>> 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 <
>> bruno.manata.oliveira at gmail.com> 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 <
>>> sebastian.messerschmidt at gmx.de>:
>>>
>>>> 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 listosg-users at lists.openscenegraph.orghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> osg-users mailing list
>>>> osg-users at lists.openscenegraph.org
>>>>
>>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>>
>>>>
>>>
>>> _______________________________________________
>>> osg-users mailing list
>>> osg-users at lists.openscenegraph.org
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>
>>>
>>
>> _______________________________________________
>> osg-users mailing list
>> osg-users at lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
>
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20160413/d61995f8/attachment-0003.htm>
More information about the osg-users
mailing list