Hi Carsten,
 
I got it. The problem was that I used a set() function for a field in the RenderChannel constructor (That worked without problems in 1.8 :-)).That caused the _pContainerChanges entry to be created. But the initialization of it was corrupt as the RenderChannel instance was not yet aware of its containerID. As the cleanup of pContainerChanges is triggered by containerID it was never successful.
So this is actually no bug in OpenSG but maybe it would be good to have a warning message or some kind of special handling in registerChangedContainer() if the containerID is set to 0.
 
Thanks for your help...
 
Michael
 
Gesendet: Dienstag, 24. Juni 2014 um 17:35 Uhr
Von: "Carsten Neumann" <carsten.p.neum...@gmail.com>
An: opensg-users@lists.sourceforge.net
Betreff: Re: [Opensg-users] OpenSG2.0: Changelist problems
Hello Michael,

On 06/24/2014 05:10 PM, Michael Raab wrote:
> >hmm, looking at the places where this member variable is assigned, it
> >gets reset when the ChangeList is cleared - do you ever clear yours?
> >Does _pContainerChanges point to something sensible or is it simply !=
> >NULL, but pointing at garbage?
> Seems to be reasonable; Is definitely not NULL;
> What I saw was that uiEntryDesc was set to 'AddReference', which makes
> not much sense there or?

that is quite odd. The entries are recycled, but when _pContainerChanges
is set to point to one (in FC::registerChangedContainer()) it also sets
the uiEntryDesc.

> I did not find any place where this member variable gets reset; Could
> you point me there?

ReflexiveContainer::clearChangeEntry(), called from:
- ChangeList::doClear()
- ChangeList::doApply(true)

> I call Thread::getCurrentChangeList()->clear(); after each frame..

Ok. If you put a ChangeList::dumpListSizes() right before that, what
numbers do you get? In particular IIRC if 'UC_S' > 0 (i.e. there are
uncommitted changes) calls to the containers ::changed() function may be
lost.

> > In editMFViews() after the call to editMField() does the above hold,
> > i.e. is _pContainerChanges->bvUncommittedChanges == &this->_bvChanged?
> _pContainerChanges->bvUncommittedChanges is NULL while &this->_bvChanged
> has some value...
> > If you add a call to ChangeList::dump() (say before sending it across
> > the cluster) does your VDTRenderChannel show up in any of the lists
> > dumped and how does that change over time?
> I already did this. I can see some AddRef/SubRefs and exactly one
> 'Changed' state, but this is directly after creation...

Hmm, that is sort of consistent with _pContainerChanges not being reset.
The next change after the reset should cause the it to be put back on
the CL changed dump.
I think it would be quite interesting to find out why
ReflexiveContainer::clearChangeEntry() is not called (or why it doesn't
do anything), to me that currently seems like the root of the problem.

Cheers,
Carsten

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Reply via email to