Robert, I will try to create a simpler example that clearly shows the issue. I hope this issue its not Windows only and you will be able to repeat it.
Cheers, Wojtek > 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 _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
