Hi Wojtek, Thanks for the explanation. I don't see any crashes here unfortunately, it's typically a relief when I can as it gives a chance of debugging first hand. I've done of a review of the ViewerBase.cpp and Renderer.cpp codes that are responsible for set up the threading and running the draw traversals and it looks to me like the DataVariance changed should prevent the next frame from advancing before the GLObjectVisitor has completed.
I would have liked to get this bug fully characterised and fixed before 2.4, but given how close we are to the release, and how open ended this quest might be, I feel that we should push ahead on 2.4, and in the 2.5.x dev series fully shake down the multi-threaded RTT beast. Robert. On Thu, Apr 24, 2008 at 2:42 PM, Wojciech Lewandowski <[EMAIL PROTECTED]> wrote: > Hi Robert, > > > > What issues were you seeing at your end? Also how did you monitor the > > race condition? > > Did problems still occur after you added the DataVariance setting? > > I have some time now, and I decided to investigate what is the context of > these Windows/multimonitor/multithread/FBO crashes. I don't have any hard > evidence but usually when such crashes occured I had some GLObjectsVisitor > traversals on the call stack. > > So I started to debug with VS 2008 and after some breakpoint stop I noticed > such case on Threads/Cull Stack. I was surpirsed to see that one thread was > inside drawable->apply( state ) method and main thread was in Update > Callback. > > I noticed that drawable did not have DYNAMIC variance set so I added it but > issue did not disappear. > > I believe that when threading is stopped and restarted GLObjectsVisitors are > invoked. So I started to suspect that this race condition might be involved > in crashses when changing threading modes with Threading Handler. I suppose > multimonitor use might be also affect it somehow (at least initialization of > synchronization barriers and blocks is). > > Currently I am further investigating it by freezing and activating some > threads and stepping through selected threads but I am freely able to repeat > this scenarios without deadlocks(caused by my debug thread suspends). So it > looks like synchronization blocks and barriers do allow for such case. Of > course without my manual interventions it does not happen so often but it > still occurs every few runs. > > Thanks, > Wojtek > > > > > > > > > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
