[osg-users] image is not being freed
Bruno Oliveira
bruno.manata.oliveira at gmail.com
Wed Apr 13 06:24:22 PDT 2016
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 <robert.osfield at gmail.com>:
> 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
>>
>>
>
> _______________________________________________
> 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/9c68f580/attachment-0003.htm>
More information about the osg-users
mailing list