An update...left the osgtext --mt demo running all night on both systems, both had crashed by the time I got up this morning.
On 8/30/07, Robert Osfield <[EMAIL PROTECTED]> wrote: > > Hi Sherman, > > Thanks for the ThreadChecker output, just scanned through it. I don't > know how to interpret all the various warnings. > > W.r.t crash on exit, I can recreate that here, and strongly suspect > its an order of destruction issue caused by the DeleteHandler caching > objects. I am considering avoiding use of DeleteHandler, but this > will require use of ref_ptr<> in some way in the rendering backend, > something that could have a significant performance impact unless we > are really careful. This is a different topic to text threading issue > though. > > Since there are lots of warnings, it'd be nice to isolate the > different problems more, and fix them all - if they are real problems > rather than false positives. Doing such a complete purge will take > some time though. > > Robert. > > On 8/30/07, sherman wilcox <[EMAIL PROTECTED]> wrote: > > I ran this on two different systems. > > > > Dell 470 - Windows XP 32 dual processor nVidia FX 3400 : no crashes at > > runtime, ran extensively, exited cleanly > > Dell 490 - Windows Vista 64 Quad Core nVidia 8800GTX : no crashes at > > runtime, crashes on exit in the delete handlers. The crash on exit isn't > > consistent, have to run it for a while. There's a call stack from the > crash > > at the bottom of my message. > > > > In both tests I was using the DrawThreadPerContext threading model. > > > > I ran Intel ThreadChecker 3.1 against this test app on the XP32 box. > I've > > attached the logfile from threadchecker. I'm afraid there's a lot of > "noise" > > in there, but hopefully it will help someone. If you find the > threadchecker > > output interesting and wish to pursue it further, I'm willing to host a > > WebEx meeting and allow you to pop in on one of my dev boxes to further > > investigate with me if you like. > > > > > > > > > > > osg.dll!std::list > <osg::ref_ptr<osg::Operation>,std::allocator<osg::ref_ptr<osg::Operation> > > > >::clear() Line 826 + 0x19 bytes C++ > > osg.dll!osg::OperationQueue::~OperationQueue() Line 56 + > > 0x43 bytes C++ > > osgViewer.dll!osg::OperationQueue::`scalar deleting > > destructor'() + 0x9 bytes C++ > > osg.dll!osg::DeleteHandler::flushAll() Line 141 + 0x10 > > bytes C++ > > osgViewer.dll!osgViewer::`dynamic atexit destructor for > > 'createWindowingSystemInterfaceProxy''() + 0x21 bytes C++ > > osgViewer.dll!_CRT_INIT(void * hDllHandle=0x00db0000, unsigned long > > dwReason=939280740, void * lpreserved=0x00000001) Line 412 + 0x9 bytes > C > > osgViewer.dll!__DllMainCRTStartup(void * > > hDllHandle=0x00db0000, unsigned long dwReason=0, void * > > lpreserved=0x00000000) Line 512 + 0x8 bytes C > > osgViewer.dll!_DllMainCRTStartup(void * > > hDllHandle=0x00db0000, unsigned long dwReason=0, void * > > lpreserved=0x00000001) Line 462 + 0x11 bytes C > > [EMAIL PROTECTED] () + 0x14 bytes > > [EMAIL PROTECTED]() - 0xd1 bytes > > [EMAIL PROTECTED]() - 0x13 bytes > > kernel32.dll!761292c7() > > msvcr80.dll!___crtExitProcess() + 0x14 bytes > > msvcr80.dll!__cinit() + 0x102 bytes > > msvcr80.dll!_exit() + 0xd bytes > > osgtest.exe!__tmainCRTStartup() Line 614 C > > [EMAIL PROTECTED]@12() + 0xe bytes > > msvcr80.dll!_exit() + 0xd bytes > > osgtest.exe!__tmainCRTStartup() Line 614 C > > [EMAIL PROTECTED]@12 () + 0xe bytes > > [EMAIL PROTECTED]@12() + 0xe bytes > > > > > > > > > > On 8/28/07, Robert Osfield <[EMAIL PROTECTED]> wrote: > > > > > > To help in the process of isolating and fixing the osgText threading > > > issues users have seen I have modified the osgtext example to do text > > > creation in a background thread. You can now run it via: > > > > > > osgtext --mt > > > > > > What you will see on screen is a box with text strings randomly > > > appearing/disappearing in the box. > > > > > > As yet I haven't see any crashes due to the font glyphs being queried > > > at the same time the text is being updated - which was the point of > > > the example code... These are the ones Ewe's changes look like they > > > might address. > > > > > > I have also added the stats handler into the example to allow us to > > > see the performance, but also by coincidence it adds a failure mode - > > > when you enable stats freetype errors start appearing. These errors > > > look to be down to freetype being based around a state model where one > > > of threads is setting the sizes and current fonts to one thing and the > > > other thread is try at the same time to set them to another. > > > Freetype itself might not be thread safe either, but my current feel > > > is that we might need more than just serializing access to freetype, > > > we'll need to group several operations at once and serialize these > > > batches. > > > > > > Robert. > > > _______________________________________________ > > > 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
