Hello Martin,
Martin Karlsson wrote:
> The backtrace is at the bottom of this mail.
thanks.
> > subChild decreases the reference count of the removed child. Why do
> > you call subRefCP manually as well, is there a corresponding addRefCP
> > call in portions of the code you did not post ?
>
> I don't have any addRefCP, I simply tried the subRefCP because the
> memory usage of the program just gets bigger and bigger during
> execution.
There is one datastructure in OpenSG that grows without bound, it is a
vector in FieldContainerFactory that maps field container ids to field
containers. But that is usually only a problem when you create huge
numbers of objects. By the way, your program looks as if it leaked a
Barrier, per call to callSync ;)
> And I thought that by decreasing their reference one more,
> the garbage collector would remove the objects.
The objects will be destroyed when their refcount is decreased to less
than one. You can inspect the refcount with fcptr.getRefCount() where
fcptr is a FieldContainerPtr (or something derived from it) -- note the
"." instead of "->" as a function of the pointer itself is called.
> Although it did not help
> and I've forgot to remove line. How to actually destroy an object?
Decreasing the refcount should do the trick, but doing it manually
should be done with care, especially if there is no corresponding
addRefCP call.
> > hm, why this line ? Do you need to pull in changes from the
> > "getClientThread()"-thread ?
> > Additionally, it does not seem to be protected by barriers, which
> > might be the reason for the errors you see.
>
> The program generally "survives" much longer if i pull the changes.
> Still the program crashes of the same reasons even if I don't pull the
> changes, so this line doesn't really help in the long run :).
>
> About the barrier; barrier syncning is done using the command:
> getClient()->callSync();
this call holds the main thread until the client thread has performed
one call to the display function (the if(needSync) part). After callSync
has returned you can not make any assumptions about the point of
execution in the threads.
This means when you call
getClientThread()->getChangeList()->applyAndClear(); the client thread
might be doing anything (possibly transmitting the change list across
the cluster) and then you clear it...
Why that line lets your program run longer is quite a mystery to me, if
anything I'd expect it the other way around. Weird.
> The external thread sets needSync to true and enter a barrier (inside
> the client class). And the glut main loop notices that needSync is true,
> and enter syncning.
> Look further up in the previous mail to see the function.
> I sync after deletion of all "dots", and after I added a number of
> "dots" to the scene. More synchronization should not be needed?
Sorry, I was not precise. There are two kinds of synchronization here,
one involves moving changes from one aspect to another one, the other
type is synchronization of threads. Performing the former should only be
done after ensuring the latter, i.e. you should have both threads at
known points of execution (usually one waiting at a Barrier::enter, the
other fetching and applying the changelist) when you apply changelists.
> Hopefully the back trace will shed some light, cause I don't understand
> whats happening :)
Hm, I don't really know either at the moment. Could you set the
environment variable OSG_LOG_LEVEL to DEBUG (on the client and the
servers) and post the output please.
Thanks,
Carsten
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
