Gerrit Voß 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.
We shouldn't be doing this, but i can't prove it. That is actually the most frustrating part of the process is that when the crashes or failures occur there isn't a lot of good information to point out what caused them. When we get more time to look at this in full detail, I think it would be a good idea to add some debug only code (maybe a compile time option) that keeps track of a bit more state information so the stack traces can be more helpful. (for example object type names or something like that). In the meantime, I think the question Dirk raised is the key one. Namely, what consistency model do we want OpenSG to support in these cases and what does it support currently. As you said, there is a lot to be gained from allowing many background threads to be running as producers all sharing the same aspect. If done right it can give much higher performance then an aspect-based solution, but we need to put some tight constraints on exactly what should be allowed. Then hopefully we could write some nice stress tests to make sure the system supports it. It is not that these come up all the time, they are 1 in a million occurrences. But in our application, 1 in a million happens every 10 minutes or so. :) Thanks for all the help. -Allen ------------------------------------------------------------------------------ _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
