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
