Hi Fredrik,
On Sat, Jun 6, 2009 at 10:53 AM, Robert Osfield 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 branch. These
are to i
HI Fredrik,
On Sat, Jun 6, 2009 at 12:58 AM, Fredrik
Orderud 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 help. :-)
Good to hear
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
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 addressi
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 w
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_content&view=article&id=52
I don't know the OSG code enough in detail
Hi Fredrik,
On Mon, May 25, 2009 at 3:07 PM, Fredrik Orderud
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 greatly appreciate if you comm
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,
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 bi
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:
http://forum.openscenegraph.org
Oooops Please disregard the suggestion in my previous posting. What I meant
to suggest was:
--
static RenderBinPrototypeList* renderBinPrototypeList()
{
osg::Referenced::getGlobalReferencedMutex();
static osg::ref_ptr s_renderBinPrototypeList = new
RenderBinPrototypeList;
return
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 (osg/
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? Ha
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 mut
14 matches
Mail list logo
