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
