Hi Robert, Yes you will be able to reproduce the valgrind output with the the code sample in the email.
Cheers, Cedric -- +33 659 598 614 Cedric Pinson mailto:cedric.pin...@plopbyte.net http://www.plopbyte.net On Fri, 2009-10-09 at 14:24 +0100, Robert Osfield wrote: > 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 >
signature.asc
Description: This is a digitally signed message part
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
