While looking through the clear code I had a question about how ReflexiveContainer::clearChangeEntry is called from ChangeList::doClear. It appears that the per thread change list is clearing the change entry that is per aspect. Is this correct? If so, we could have multiple threads trying to clear the same change entry.
-Aron On Tue, Mar 24, 2009 at 12:12 PM, Aron Bierbaum <[email protected]> wrote: > First let me thank you for the quick response. The change that you > made last night seems to be working very well. We are going through > some stress tests right now and should know more in a few hours. > Unfortunately we tried calling commitChangesAndClear in each > background thread to help clear memory. I actually think this is > another bug that we have been chasing for a while. Calling this method > seems to cause another crash though. I have attached the stack trace > below. Do you have any ideas why using commitChangesAndClear would > cause this and calling commitChanges would not? Does the fact that we > are calling this in a background thread actually mean that we are > changing the field container in a unsafe way? > >> OSGBase.dll!OSG::osgAtomicIncrement(long * pValue=0x2003aee4) Line >> 104 + 0x8 bytes C++ > OSGBase.dll!OSG::FieldContainer::addReferenceRecorded() Line 97 + > 0xc bytes C++ > > p5_dve_earth.dll!OSG::RecordedRefCountPolicy::addRef(OSG::FieldContainer > * const objectP=0x2003aea8) Line 63 C++ > p5_dve_earth.dll!OSG::RecordedRefCountPolicy::setRefd<OSG::Node > *,OSG::Node *>(OSG::Node * & pTarget=0x00000000, OSG::Node * > pSource=0x2003aea8) Line 74 + 0x9 bytes C++ > > p5_dve_earth.dll!OSG::RefCountPtr<OSG::Node,OSG::MTRecordedRefCountPolicy>::RefCountPtr<OSG::Node,OSG::MTRecordedRefCountPolicy>(OSG::Node > * const pObj=0x2003aea8) Line 103 + 0xd bytes C++ > p5_dve_earth.dll!dve::LandTile::getRootNode() Line 57 + 0x14 bytes > C++ > > p5_dve_earth.dll!dve::TileLayer::removeTile(boost::shared_ptr<dve::LandTile> > landTile={...}) Line 406 + 0x16 bytes C++ > p5_dve_earth.dll!dve::TileLayer::updateSectors(const unsigned char > level=' ', const > std::vector<boost::shared_ptr<dve::Sector>,std::allocator<boost::shared_ptr<dve::Sector> >> > & removed=[56]({px=0x187bee58 pn={...} },{px=0x187beee0 pn={...} > },{px=0x187bef68 pn={...} },{px=0x187beff0 pn={...} },{px=0x187bf078 > pn={...} },{px=0x187bf100 pn={...} },{px=0x187bf188 pn={...} > },{px=0x2007b020 pn={...} },{px=0x1ff546e0 pn={...} },{px=0x1ff54738 > pn={...} },{px=0x1ff547c0 pn={...} },{px=0x1ff54848 pn={...} > },{px=0x1ff548d0 pn={...} },{px=0x1ff54958 pn={...} },{px=0x1ff549e0 > pn={...} },{px= ,...), const > std::vector<boost::shared_ptr<dve::Sector>,std::allocator<boost::shared_ptr<dve::Sector> >> > & added=[0]()) Line 208 C++ > p5_dve_earth.dll!dve::Pyramid::update(const OSG::Point<double,3> & > eyeLLH={...}) Line 136 C++ > p5_dve_earth.dll!dve::SectorLayer::update(const OSG::Point<double,3> > & eyeLLH={...}, const OSG::Point<double,3> & focusLLH={...}, const > OSG::FrustumVolume & frustum={...}) Line 61 C++ > p5_dve_earth.dll!dve::TileLayer::update(const OSG::Point<double,3> & > eyeLLH={...}, const OSG::Point<double,3> & focusLLH={...}, const > OSG::FrustumVolume & frustum={...}) Line 614 C++ > p5_dve_earth.dll!dve::Planet::update(const OSG::Point<double,3> & > eyeLLH={...}, const OSG::Point<double,3> & focusLLH={...}, const > OSG::FrustumVolume & frustum={...}) Line 205 C++ > _p5_dve.pyd!boost::python::detail::invoke<int,void ( > dve::Planet::*)(OSG::Point<double,3> const &,OSG::Point<double,3> > const &,OSG::FrustumVolume const > &),boost::python::arg_from_python<dve::Planet > &>,boost::python::arg_from_python<OSG::Point<double,3> const > &>,boost::python::arg_from_python<OSG::Point<double,3> const > &>,boost::python::arg_from_python<OSG::FrustumVolume const &> >() + > 0x35 bytes > _p5_dve.pyd!boost::python::detail::caller_arity<4>::impl<void ( > dve::Planet::*)(OSG::Point<double,3> const &,OSG::Point<double,3> > const &,OSG::FrustumVolume const > &),boost::python::default_call_policies,boost::mpl::vector5<void,dve::Planet > &,OSG::Point<double,3> const &,OSG::Point<double,3> const > &,OSG::FrustumVolume const &> >::operator()() + 0x283 bytes > > _p5_dve.pyd!boost::python::objects::caller_py_function_impl<boost::python::detail::caller<void > ( dve::Planet::*)(OSG::Point<double,3> const &,OSG::Point<double,3> > const &,OSG::FrustumVolume const > &),boost::python::default_call_policies,boost::mpl::vector5<void,dve::Planet > &,OSG::Point<double,3> const &,OSG::Point<double,3> const > &,OSG::FrustumVolume const &> > >::operator()() + 0x1a bytes > boost_python-vc90-mt-1_37.dll!048a09f0() > [Frames below may be incorrect and/or missing, no symbols loaded for > boost_python-vc90-mt-1_37.dll] > boost_python-vc90-mt-1_37.dll!048a7c83() > boost_python-vc90-mt-1_37.dll!048a7ed2() > > _p5_dve.pyd!boost::python::detail::translate_exception<dve::Exception,void > (*)(dve::Exception const &)>::operator()() + 0x43 bytes > 0021eb1c() > > Thanks, > Aron > > On Tue, Mar 24, 2009 at 9:19 AM, Gerrit Voß <[email protected]> wrote: >> >> Hi, >> >> On Tue, 2009-03-24 at 09:04 -0500, Allen Bierbaum wrote: >>> On Tue, Mar 24, 2009 at 12:05 AM, Gerrit Voß <[email protected]> >>> wrote: >>> > >>> > Hi, >>> > >>> > On Mon, 2009-03-23 at 21:43 -0600, Allen Bierbaum wrote: >>> >> On Mon, Mar 23, 2009 at 8:27 PM, Carsten Neumann >>> >> <[email protected]> wrote: >>> >> > Hello Allen, >>> >> > >>> >> >> >>> >> >> * Change lists: As discussed in another posting, we think that the >>> >> >> change list should be thread safe and that as long as we call >>> >> >> commitChanges() we should be good. >>> >> > >>> > >>> > One other thought, could you call commitChangesAndClear instead of just >>> > commitChanges as you transfer your containers from one thread to >>> > the other. commitChanges leaves some entry linking intact and might >>> > have some side-effects. I have to think through the details but the >>> > AndClear version should be safer. >>> >>> I think my use of the work "sync" is a bit confusing. There is no >>> sync in terms of commiting a change list across threads in our case >>> because everything is in the same aspect. I was using "sync" to mean >>> the point in our application where we know the background request has >>> completed and we hook it up to the foreground scenegraph. In effect >>> we are handing off control of the fc's from background to foreground >>> because the bg thread won't touch them anymore and the foreground >>> thread now has full control to do with them as it will. >> >> I roughly know ;) what I meant was just before you do so can you call >> commitChangesAndClear in the bg thread. Internally the fc's have links >> to their changed entries which are used to accumulate changes over >> commitChanges calls so that during apply or cluster transfers you >> have fewer entries per container. It also helps to keep the changelist >> size in bounds. If you don't clear the containers now controlled by >> your foreground thread still have references back to the changelist >> of you background thread. I'm not 100% sure if this is the good, the bad >> or the ugly, but suspicious it is ;) That's why I suggested a AndClear. >> >> kind regards, >> gerrit > ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
