HI Fredrik,
On Sat, Jun 6, 2009 at 12:58 AM, Fredrik
Orderudfredrik.orde...@idi.ntnu.no wrote:
I have now checked out and built the current OSG trunk, and can report that
statically built OSG now terminates properly without any errors in both debug
and release. Thank you very much for your
Hi Fredrik,
On Sat, Jun 6, 2009 at 10:53 AM, Robert Osfieldrobert.osfi...@gmail.com wrote:
Now I've got confimation that this fix works I will put in a separate
fix for the OSG-2.8 branch, this should be possible to backport to
OSG-2.8.1.
I've now checked in the required changes the OSG-2.8
Hi Fredrik,
Thanks for the link, the suggestion of depends_on does look to be a
good thing in our context, it will break the ABI though so it's not an
approach we could use in the OSG-2.8 branch. Your suggestion of an
explictly initializer in singleton implementation would be less
elegant but
Hi Fredrik,
I've got the following to compile, could you test it out at your end.
This code is all the .cpp right now so doesn't affect the ABI so could
be rolled into the 2.8 branch. I've also attached the the whole
RenderBin.cpp, but this is based on svn/trunk.
I this is successful at
I have now checked out and built the current OSG trunk, and can report that
statically built OSG now terminates properly without any errors in both debug
and release. Thank you very much for your help. :-)
Your RenderBin_195.cpp hotfix, however, causes an compile error when
incorporating it
I've just discovered a potential solution for the initialization order for
static objects. You can use the depends_on-pattern to let your classes
inherit their dependencies.
http://www.entropygames.net/index.php?option=com_contentview=articleid=52
I don't know the OSG code enough in detail to
Hi Fredrik,
Good detective work. I'd be afraid that adding this
osg::Referenced::getGlobalReferencedMutex(); would not be a general
solution, and a little reordering by the compiler could easily cause
some other static created object to then break the destruction. I'd
therefore like to look a
I agree that my proposed fix is limited to s_renderBinPrototypeList, and
similar problems from other static objects can surface at a later time.
However, I fear that I can prove difficult to create an elegant infrastructure
for ordering the construction of static objects in a bullet-proof way.
Hi Fredrik,
On Mon, May 25, 2009 at 3:07 PM, Fredrik Orderud
fredrik.orde...@idi.ntnu.no wrote:
As of today, OSG _always_ crashes upon program termination when using static
OSG libs. This is a big annoyance, and it makes it difficult to debug other
code that uses OSG. I would therefore
It appears that others are also experiencing RenderBinPrototypeList destruction
problems when building osg as a static lib:
http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2009-April/026550.html
--
Read this topic online here:
I have now debugged the problem a bit, and it does indeed manifest itself under
both Win32 debug and release builds. The root of the problem is that the static
s_renderBinPrototypeList object (osgUtil/RenderBin.cpp line 44) is being
created before the static s_ReferencedGlobalMutext object
Oooops Please disregard the suggestion in my previous posting. What I meant
to suggest was:
--
static RenderBinPrototypeList* renderBinPrototypeList()
{
osg::Referenced::getGlobalReferencedMutex();
static osg::ref_ptrRenderBinPrototypeList s_renderBinPrototypeList = new
Hi Fredrik,
I haven't seen reports of problems relating to renderbin destruction
before. Perhaps you use of a static build of the OSG/OT is what is
uncovering the issue. It seems odd that a dependent library would be
destructed after objects in the core. What happens on the release
build?
There seems to be a problem with the destruction order for the static
objects in OpenSceneGraph. At program termination when executing in debug
mode, I get a mutex lock error in the destructor for
s_renderBinPrototypeList (osgUtil/RenderBin.cpp line 44). This error is
caused by the static
14 matches
Mail list logo
