Hi,
On Tue, 2009-03-24 at 22:47 -0500, Aron Bierbaum wrote:
> On Tue, Mar 24, 2009 at 10:23 PM, Gerrit Voß <[email protected]> wrote:
> >
> > Hi,
> >
> > On Tue, 2009-03-24 at 16:10 -0500, Carsten Neumann wrote:
> >> Hello Aron,
> >>
> >> Aron Bierbaum wrote:
> >> > 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
> >>
> >> there is only one place this is called from: FieldContainer.cpp:203
> >> (FieldContainer::registerChangedContainer()). Since this normally makes
> >> sure that the argument passed to addUncommited is != NULL there must be
> >> a race between two threads modifying the same container. I can't think
> >> of another explanation that would ever allow a NULL argument passed to
> >> addUncommited.
> >
> > it sounds more like one thread is modifying the container while another
> > one is running through doClear.
> >
> > Three questions, what is the type of the container calling
> > addUncommited, in which thread is the assertion triggered and
> > what is/are the other threads doing at that point in time.
> >
> > Given that you only seem to share materials the only good initial
> > guess I have is that you trigger something because you changed the
> > texture drawing to actually modify the image container.
> >
> > kind regards,
> > gerrit
>
> I have had limited time testing this because on such a short time
> frame we might be willing to accept not clearing the change list and
> deal with the leak. With that said the only information that I have is
> that I added some simple code to print the type when it detected a
> race condition like this. The first type that I found was
> PassiveWindow, which does not make sense to me.
hmm interesting, I'll run it around my head.
> I will hopefully get
> time tomorrow to test this further to get more information. Two
> questions then:
>
> 1) As far as I know I am not adding any GL objects to the Window in
> the background thread, can you think of any other reason something
> else would be changing a PassiveWindow while we are clearing the
> change list?
I'll walk through it, windows can be tricky as some of the static
functions walk through a static list of all windows to update things.
> 2) Could we get a memory improvement by calling the protected method
> clearPool() and ignore doClear() for now? I know that we would still
> have a change entry for each FC and the shared aspect, but wouldn't we
> be able to clear the per thread references?
No that isn't a good idea because than the changed entries referenced by
one container would be reused by another one.
If you run into changelist memory problems there are two things you can
try, unless you need clustering but so far it did not sound like.
1) the easy one is do not use recorded pointers . With recorded pointers
a changelist entry is created for any addRef/subRef. For your app
it should be ok to use the unrecorded variant as you neither use
the cluster nor use different aspects with changelist->apply.
1a) if you want to keep using Rec pointers we could add a function
that purges these entries from the changelist so that it does
not grow to much.
2) I re-added a readonly changelist compile time option a while ago
which should keep the changelist size bound by the number of
live containers. Though I haven't done much testing on that part.
> If we really need to do this in the short term I think we could check
> each frame to see if any threads are active, and if they are not we
> could clear the change lists. This would delay the clear, but would
> still clear the memory.
hmm one thing I was thinking about is to add a cheap spinlock to the
containers so that we can serialize access under certain conditions. I
need this one anyway to sync multiple aspects in parallel, which
currently also does not work. My biggest problem is to get the windows
version right as for linux harvesting the kernel sources usually gives
good hints ;)
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
