Hi, On Tue, 2007-09-25 at 14:02 -0500, Carsten Neumann wrote: > Hi Gerrit, > > I'm trying to debug a crash I see which might be introduced/triggered by > the ref count/pointer changes I'm working on, but along the way I've > noticed some things that seem strange to me: > > - it seems we create created/changed entries in the CL for the > prototypes, is this correct behavior ? The entries are created because > the createEmpty macros use FieldContainer::newPtr<> which in turn calls > onCreate, which calls registerChangedContainer.
that should be ok. Just wipe the ChangeList after osgInit. Actually we could automatically do it at the end of osgInit. Though the MT prototype handling is not quite right yet. > - The macros for the create functions use FieldContainer::newPtr<Self> > to create new instances and newPtr<ObjectT> just does new ObjectT, which > AFAICS defeats the prototypes, because they are not cloned anymore and > the type of the created object is determined statically from the object > used to issue the create call. Am I missing something here ? which macros ?. All the creates I see clone the prototype. The createEmpty functions don't but this is intended. Do you have a filename/line no reference. > Debugging of the crash mentioned above shows that the problem seems to > be the call pTmp->changed(...) in ContainerChangeEntry::commitChanges. > gdb insists that pTmp points to an instance of FieldContainer, which > should be impossible as it is a pure virtual class. Have you seen > something like this before ? crappy gdb behaviour, sure tons of it. It's like ATI drivers, when in doubt blame them. But actually one short question do you run gdb in 'actual' or 'declared' object type mode ?. Declared would at least explain the behaviour because gdb will ignore the rtti info. Could you try 'show print object', if this says off try 'set print object' and than see if it makes a difference. Interestingly 'declared' object mode seems to be the default. kind regards, gerrit ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Opensg-core mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-core
