Most recently I have run into a situation where I get the following assert. Any ideas how this is possible?
Assertion failed: 0 != pEntry, file ..\..\..\vendor_base\Source\Base\FieldContainer\Base\OSGChangeList.cpp, line 147 -Aron On Tue, Mar 24, 2009 at 12:18 PM, Aron Bierbaum <[email protected]> wrote: > 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
