Hi Antonio, > Hi Carsten, > > Carsten Neumann wrote: > >> Hi Antonio, >> >>On Wed, 2007-09-05 at 19:52 +0200, Antonio Bleile wrote: >> >>>Hi, >> >>[SNIP] >> >>> LockCount -17891601 long >>> RecursionCount -17891602 long >>> OwningThread 0xfeeefeee void * >>> LockSemaphore 0xfeeefeee void * >>> SpinCount 4277075694 unsigned long >> >>>where OwningThread seems quite suspicious... >> >>indeed, but the interesting question is of course why it has that >>strange value ;) >> >> >>>If I remove the addRefCP and subRefCP calls, the osgExit works >>>ok. osgInit, the rendering etc and osgExit run all in the same >>>thread! The context and the PassiveWindow is deleted _before_ >>>calling osgExit(). Any ideas? >> >>No, sorry, none right now, only that I would not be too surprised if >>this is related to the ThreadManager::shutdown crashes reported by >>Gabriel yesterday. >>The problem is that without being able to reproduce these cases (ok, I >>haven't tried yet) it looks hard to figure out. You don't happen to have >>a small reproducing testcase, do you ? ;) > > > I'm trying very hard. But it doesn't crash.... I observed that the > actual crash does not occur in the subRefCP but in the destructor > of the instance which has some OSGPtr's as members. Using > and deleting the instance withing the OpenSG tutorial's works fine > though. I'm not able to see on which member destruction it crashes > with the debugger...(if it does so...). > > Regards, > > Toni
in the scons build system there exist a "invalid_pointer_check" option if you enable this the addRefCP, subRefCP, ... methods are replaced by some special macros and with these it is possible to detect a subRefCP call on a already destroyed pointer. Actually it will report the exact source code line with the invalid subRefCP call as a FATAL error message. As usual there er some drawbacks with this option, ok the check costs a bit processor time, and if you call addRefCP, subRefCP with the OSG namespace like OSG::subRefCP this won't work. If someone knows a solution how to write a macro that works with a namespace ... Andreas -- VREC Robert-Bosch-Straße 7 D-64293 Darmstadt Tel. 06151-4921035 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
