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. 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? 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? 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. -Aron ------------------------------------------------------------------------------ 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
