Hi Cedric,
Thanks for keep on digging into this problem. I don't think this is a
bug in your code, rather you've just set up a set of circumstances
that the normal clean up is circumvented and an errors occurs. If
possible we should find a way of avoid the problem in full range of
usage.
Does the little example app you provided in your email reproduce the
crash on exit? Could we use this as a unit test?
Robert.
On Fri, Oct 9, 2009 at 1:49 PM, Cedric Pinson
<cedric.pin...@plopbyte.net> wrote:
> Hi again,
>
> ok i found my mistake and it could help other people that have a strange
> behaviour when quitting. I make a small code to reproduce the problem.
> At the end i did
> myviewer.setSceneData(0);
> in order to remove scene. With the new texture manager it produces this
> valgrind output in attached file. I did not think it was bad to do that.
> anyway if this post can save time for other people...
>
>
> #include <osg/ref_ptr>
> #include <osgDB/ReadFile>
> #include <osgDB/Registry>
> #include <osgViewer/Viewer>
> #include <osg/StateSet>
> #include <osgText/Text>
> #include <osg/Texture2D>
>
> int main(int argc, char** argv)
> {
> osg::ref_ptr<osg::Group> grp = new osg::Group;
> osgViewer::Viewer myviewer;
> myviewer.setSceneData(grp);
>
> osg::ref_ptr<osg::Geode> geode = new osg::Geode;
> osg::ref_ptr<osgText::Text> chipsText = new osgText::Text;
> std::string fontName = "../data/Vera.ttf";
> int size = 20;
> osg::Vec3 pos(0,0,0);
> osg::ref_ptr<osgText::Font> font =
> osgText::readFontFile(fontName.c_str());
> chipsText->setFont(font);
> chipsText->setText("blabla");
> geode->addDrawable(chipsText);
> grp->addChild(geode);
>
> myviewer.realize();
> myviewer.run();
> myviewer.setSceneData(0);
> return 0;
> }
>
>
>
> --
> +33 659 598 614 Cedric Pinson mailto:cedric.pin...@plopbyte.net
> http://www.plopbyte.net
>
>
> On Thu, 2009-10-08 at 15:22 +0200, Cedric Pinson wrote:
>> Hi Robert,
>>
>> I updated to the svn trunk today, and i can notice a crash when quitting
>> my application. To be sure it was with the new texture manager i defined
>> USE_NEW_TEXTURE_POOL to 0 and then to 1.
>>
>> I dont have yet found the problem, but i guess it's linked with my
>> texture manager, i own some static that reference texture.
>>
>> The segfault appear when quitting
>> Program received signal SIGSEGV, Segmentation fault.
>> #0 0xb6ef7ddf in ?? () from /lib/libc.so.6
>> #1 0xb5dddc40 in ?? () from //usr//lib/opengl/nvidia/lib/libGLcore.so.1
>> #2 0xb5dddc40 in ?? () from //usr//lib/opengl/nvidia/lib/libGLcore.so.1
>> #3 0xb54f2008 in ?? ()
>> #4 0xb54f2008 in ?? ()
>> #5 0xb6193d60 in ?? () from //usr//lib/opengl/nvidia/lib/libGLcore.so.1
>> #6 0xb6fd0bcb in ?? () from /lib/libc.so.6
>> #7 0xb6fd26e8 in ?? () from /lib/libc.so.6
>> #8 0xb6fcf469 in ?? () from /lib/libc.so.6
>> #9 0xb6fcf442 in ?? () from /lib/libc.so.6
>> #10 0xbfc68254 in ?? ()
>> #11 0xa7200010 in ?? ()
>> #12 0x0000001d in ?? ()
>> #13 0x00000000 in ?? ()
>>
>> I guess there is something wrong with my texture management and the new
>> texture pool.
>>
>> I continue to dig
>>
>> Cheers,
>> Cedric
>>
>> --
>> +33 659 598 614 Cedric Pinson mailto:cedric.pin...@plopbyte.net
>> http://www.plopbyte.net
>>
>>
>> On Fri, 2009-10-02 at 22:21 +0100, Robert Osfield wrote:
>> > Hi All,
>> >
>> > I've been pretty quiet and the public list/forum through September,
>> > keeping my head down developing new functionality for the OSG... and
>> > the new functionality I'm pleased to announce today is that we now
>> > have a loverly new back-end implementation for texture objects and
>> > buffer objects (VertexBufferObject, ElementBufferObjects and
>> > PixelBufferObjects's) that provides a set of GL objects pools that
>> > enable recycling of both orphaned GL objects and reuse of GL objects
>> > that are still attached to the scene graph, but are stale - i.e.
>> > haven't been rendered in the last frame.
>> >
>> > The benefit the GL object pools provide is that we can scale up the
>> > scene graph in main memory without blowing OpenGL driver and GPU
>> > memory as we would do without the new pools. This feature also
>> > reduces the likely-hood of thrashing of OpenGL driver and GPU memory
>> > so that where we might have previously seen frame drops due to memory
>> > management we avoid them completely or reduce there impact. The
>> > memory pools will come in there own once we scale down the GPU memory
>> > size, such as embedded systems, or on desktop/workstation applications
>> > where GPU memory can be overflowed due to massive databases being kept
>> > in main memory. In the later case this issue is more compounded on
>> > some OS's, such as Vista, that limits the amount of memory that OpenGL
>> > drivers can allocate, so here it should help make the app more stable
>> > (avoid the crashes due to out of memory errors) and faster.
>> >
>> > So... how to try out the new texture and buffer object pools? First
>> > up you'll need to update to the latest OpenScenGraph svn/trunk. Next
>> > you'll need to enable the pools by setting the env vars: (example
>> > below for bash)
>> >
>> > export OSG_TEXTURE_POOL_SIZE=100000000 // size in bytes (100Mb)
>> > export OSG_BUFFER_OBJECT_POOL_SIZE=200000000 // size in bytes (200Mb)
>> >
>> > Then run your app with some big data, such a large paged database, you
>> > can push the amount of main memory used by enabling the MaxPagedLOD
>> > feature in the DatabasePager via:
>> >
>> > export OSG_MAX_PAGEDLOD=100000 // keep in memory a maximum of
>> > 100,000 PagedLOD nodes
>> >
>> > You can also set these values programmatically via osg::DisplaySettings.
>> >
>> > A word of warning though, I have almost completely rewritten the way
>> > that the backend that drives texture objects and buffer objects, even
>> > when you don't enable the texture/buffer object pools, the code
>> > managing the GL objects is still completely different. With major
>> > changes like this comes the likelihood of regressions. I've been
>> > doing a range of tests at my end, but it's still far more limited in
>> > scope to what the community will expose the OSG to, so... there you
>> > may way see problems that I haven't. The best I can do is endeavor to
>> > get them fixed as quickly as possible, just let me know if you see
>> > something odd and I we can work together to spot what the underlying
>> > problem and squish it. The more testing we can get the quicker we can
>> > shape the code up to being release quality.
>> >
>> > Have fun with it :-)
>> > Robert.
>> > _______________________________________________
>> > osg-users mailing list
>> > osg-users@lists.openscenegraph.org
>> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>> >
>> _______________________________________________
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
> _______________________________________________
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
