Hi, On Wed, 2012-10-03 at 09:20 +0000, Halm, Andreas wrote: > Hi, > > What does this mean? I get a crash directly after these warnings so i am sure > they are related ... > > OpenSG WARNING: OSBRootElement::mapPtrField: FieldHandles invalid, can not > set pointer - target fc [528] fieldId [8] file id [475] system id [528] > OpenSG WARNING: OSBRootElement::mapPtrField: FieldHandles invalid, can not > set pointer - target fc [539] fieldId [8] file id [471] system id [539] > OpenSG WARNING: OSBRootElement::mapPtrField: FieldHandles invalid, can not > set pointer - target fc [542] fieldId [8] file id [502] system id [542] > OpenSG WARNING: OSBRootElement::mapPtrField: FieldHandles invalid, can not > set pointer - target fc [553] fieldId [8] file id [498] system id [553] > OpenSG WARNING: OSBRootElement::mapPtrField: FieldHandles invalid, can not > set pointer - target fc [556] fieldId [8] file id [529] system id [556] > OpenSG WARNING: OSBRootElement::mapPtrField: FieldHandles invalid, can not > set pointer - target fc [567] fieldId [8] file id [525] system id [567] > OpenSG WARNING: OSBRootElement::mapPtrField: FieldHandles invalid, can not > set pointer - target fc [528] fieldId [6] file id [475] system id [528] > OpenSG WARNING: OSBRootElement::mapPtrField: FieldHandles invalid, can not > set pointer - target fc [542] fieldId [6] file id [502] system id [542] > OpenSG WARNING: OSBRootElement::mapPtrField: FieldHandles invalid, can not > set pointer - target fc [556] fieldId [6] file id [529] system id [556]
can you easily identify which fields are behind 8 and 6 and let me know what kind of ptr fields have a problem. The fcd field part and the corresponding getHandleXXXX editHandleXXX function definitions for the particular fields would be a great help. > Unfortunately I couldn't find anything about these so they probably aren't > happening so often ... > So these happen while loading a .osb file, containing some custom field > containers (all nodecores) and saved with the same program. > The classes are not in a seperate DLL, but statically linked. They are > heavily cross-linked which may be the problem - the loader does not seem to > be > able to recreate the links. The "crash" (assert) happens in a call to > changed() when some of the pointers are 0. As long as the system can create the container, which seems to be the case, it is properly registered with OpenSG and there should not be any follow-up problem where the code is actually located. > Any idea where to go from here? I could of course go for some home-brewn > save/load mechanism but i would rather not... let's have a look first ;) kind regards gerrit ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
