Hi Carsten, I finally got the backtrace, it is attached to this mail. Among other things, RemoteAspect::receiveSync is called. In this function I found the following comment:
// subref until the factory hat no // knowlage of the node // we can do this here because in sendSync the destroys are coming // after the changes, that's important because if // rebuildState would be called // after the StateChunk has been destroyed this would lead to some // problems because the StateChunk is also referenced // in the state and in the next rebuildState of the material // the old already invalid chunk ptr is destroyed again! May this has something to do with this crash? Thanks & Best regards, Michael -------- Original-Nachricht -------- > Datum: Wed, 14 Apr 2010 15:00:51 -0500 > Von: Carsten Neumann <carsten_neum...@gmx.net> > An: opensg-users@lists.sourceforge.net > Betreff: Re: [Opensg-users] OpenSG1.8 - Destroying Materials in ClusterMode > Hello Michael, > > Dirk Reiners wrote: > > I've got a crash when running OpenSG in cluster mode. I'm creating and > > destroying some ChunkMaterials during runtime. This causes a crash of > the server > > application. Using the debug libraries of OpenSG the server runs fine > but I > > noticed some of the following lines in the log: > > > > WARNING: FieldContainerFactory::unregisterFieldContainer:id -572662307 > > inconsistent with store size 8034! > > hm, this almost looks as if the data is corrupted or the network > protocol got out of sync. > > > Looking into the code this message is only generated in debug mode > > yes, unfortunately debug mode will then just never release the > _pStoreLock :-/ I'm surprised this does not just hang afterwards? > > > and the > > origin of the crash (most likely an out of bounds array access) is > avoided, see: > > yes, the question is where that odd value for the container id comes from? > Where does the call to unregisterFieldContainer come from, i.e. can you > get a backtrace - perhaps by setting a conditional breakpoint in the > function that triggers only if pFieldContainer.getFieldContainerId() is > unusually large? > > > I'll attached my full trace for your information. So am I doing > something wrong > > or is this a bug in OpenSG? (The trace is at > > http://drop.io/OpenSG_Cluster_Problem, file server.zip.) > > hm, I'd say it looks like a bug or at the least some subtle assumption > in OpenSG. I'm just not quite sure how to track it down, so far my > attempts to reproduce it have failed. The log unfortunately does not > give a good idea where the unusual container id values come from. > > Cheers, > Carsten > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Opensg-users mailing list > Opensg-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/opensg-users -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ------------------------------------------------------------------------------ _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
