Hi George, I'm afraid I really can't help you it hunting down what the issue is as I haven't used Windows for development for over a decade. I have read that are problems with MS's stream implementation which may well be what is the root cause of the problems you are seeing. Try another platform to see if this gives you any more insight.
Robert. On 1 December 2011 16:35, George Bekos <[email protected]> wrote: > Hello again! > > Thanks for your reply Robert. I want to apologise because I was wrong when I > said that the problem goes away when you remove the _log<<message line. Even > if I have an empty osg::NotifyHandler::notify() function, it will still crush > (although it might take some time)! This is what I have now: > > Code: > > #include <osg/Group> > #include <osg/Notify> > #include <osgViewer/Viewer> > > class LogFileHandler : public osg::NotifyHandler > { > public: > LogFileHandler(void) {} > void notify( osg::NotifySeverity severity, const char* message ) {} > protected: > ~LogFileHandler(void) {} > }; > > int main( int agc, char** argv ) > { > osg::setNotifyLevel(osg::DEBUG_FP); > osg::Group* root = new osg::Group(); > LogFileHandler* fileHandler = new LogFileHandler(); > osg::setNotifyHandler(fileHandler); > osgViewer::Viewer viewer; > viewer.setSceneData(root); > viewer.setUpViewInWindow(50,50,800,600); > viewer.run(); > return 0; > } > > > > Here is a call stack from the crush: > > Code: > > msvcr90d.dll!operator delete(void * pUserData=0x00908740) Line 52 + 0x51 > bytes C++ > msvcp90d.dll!std::allocator<unsigned short>::deallocate(unsigned short * > _Ptr=0x00908740, unsigned int __formal=102) Line 146 + 0x9 bytes C++ > msvcp90d.dll!std::basic_stringbuf<char,std::char_traits<char>,std::allocator<char> > >::overflow(int _Meta=0) Line 148 C++ > msvcp90d.dll!std::basic_streambuf<char,std::char_traits<char> >::sputc(char > _Ch=0) Line 163 + 0x4a bytes C++ > osg80-osgd.dll!osg::NotifyStreamBuffer::sync() Line 73 + 0xd bytes C++ > msvcp90d.dll!std::basic_streambuf<unsigned short,std::char_traits<unsigned > short> >::pubsync() Line 101 C++ > msvcp90d.dll!std::basic_ostream<unsigned short,std::char_traits<unsigned > short> >::flush() Line 552 + 0x30 bytes C++ > msvcp90d.dll!std::endl(std::basic_ostream<char,std::char_traits<char> > & > _Ostr={...}) Line 975 C++ > msvcp90d.dll!std::basic_ostream<unsigned short,std::char_traits<unsigned > short> >::operator<<(std::basic_ostream<unsigned > short,std::char_traits<unsigned short> > & (std::basic_ostream<unsigned > short,std::char_traits<unsigned short> > &)* _Pfn=0x65983a20) Line 173 + 0x7 > bytes C++ > osg80-osgViewerd.dll!osgViewer::Renderer::draw() Line 645 + 0x63 bytes C++ > > > > Although the last 4 calls (sputc() call to operator delete call) are the same > most of the time. > Any ideas what is going on? Are all the classes and functions invoked after > using basic_ostream::operator<< supposed to be thread safe? If not, does OSG > access these functions in a thread-safe way? > It crushes on both OSG 3.0.0 and 3.0.1 (two different machines). With visual > Studio 2008 SP1 and Win7x64. > Thanks a lot for your time. > > Cheers, > George > > ------------------ > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=44167#44167 > > > > > > _______________________________________________ > 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
