Hi Carsten, I think I found the problem or even a work around. When I try to clean up unused materials, I use subChunk() in the destructor of my Material class to remove sequentially all chunks from my current ChunkMaterial. Btw, I have ein RefPtr<> on each chunk and on the ChunkMaterial. After that I set the RefPtr<> of the ChunkMaterial to NullFC! In this situation the crash occurs.
If I remove the removal of the chunks before setting the Chunkmaterial RefPtr<> to NullFC, the application runs without problems. Maybe a reference problem? Best regards, Michael -------- Original-Nachricht -------- > Datum: Thu, 22 Apr 2010 11:22:11 -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, > > Michael Raab wrote: > > I finally got the backtrace, it is attached to this mail. > > thanks! > > > 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? > > yes, to some extent at least. The comment mainly explains why it is safe > to handle a "destroy" change list entry by simply decrementing the ref > count of an object until it is destroyed - it is safe because "changed" > change list entries (that could potentially refer to the destroyed > object) will already be handled at this point (they are sent before > "destroyed" entries). The Material/State/StateChunk case is just > mentioned as a concrete example where this is important (and probably it > was discovered that way originally). > > I have a couple of questions, that hopefully will allow us to narrow > down on the real problem: > > - do you have a reliable way to reproduce the crash? What is the > sequence of things that lead to it? > You mentioned that you are creating/destroying materials, but what has > to happen to trigger the bug? I've tried to just change materials in > testClusterClient, but that alone was not sufficient, so I suspect there > is something else that has to happen. > > - are you able to reproduce the problem with testClusterClient, probably > after making some hackish modification to it (to keep it simple perhaps > just make an explicit render() call from main, make a change, call > render(), more changes if necessary, etc.) ? > > - how do you ensure your materials are correctly ref counted? Do you > store them in the application with RefPtr<MaterialPtr> (i.e. > MaterialRefPtr) or as plain MaterialPtr? Do you manually do > addRefCP/subRefCP calls? Does the problem perhaps only trigger if you > add a material to an object, remove it and then add it again? > > - can you give the attached patch a try? It fixes some missing > begin/endEditCP calls in ChunkMaterial and State. > > Cheers, > Carsten -- 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
