Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

[OpenSceneGraph Users]

On Wednesday, January 29, 2020 at 11:02:48 AM UTC+1, Robert Osfield wrote:
>
> Hi Fabian,
>
> On Wednesday, 29 January 2020 00:24:35 UTC, Fabian Roth wrote:
>>
>> Hi Chris,
>> I am using the latest openmw master with the compatibility patch from the 
>> pull request cherry picked, my build changes and minor other tweaks.
>> I use the osg rc with a only a cmake version change.
>> The branches are here:
>> https://github.com/Eli2/openmw/tree/eli2-openmw-static
>> https://github.com/Eli2/OpenSceneGraph/tree/eli2-openmw-static
>>
>> By now i strongly suspect i run into the "Static Initialization Order 
>> Fiasco", as described here:
>> https://cryptopp.com/wiki/Static_Initialization_Order_Fiasco
>>
>> I am currently looking into why my build uses the default font.
>>
>
> The way that the singleton methods are done is an attempt to resolve the 
> construction order issue, but l don't recall a focus on the destruction 
> side.  It could well be an issue.
>
> One workaround might be to add a mutex directly to the Font objects that 
> are being destructed rather than using the global one.  Or, to explicitly 
> clear the ObjectCache on destruction rather than leaving it to static clean 
> up.  The later would be my preferred approach.
>
> A call to:
>
>osgDB::Registry::instance()->getObjectCache()->clear();
>
> In application clean up should be sufficient, or force the destruction of 
> the Registry singleton:
>
>osgDB::Registry::instance(true);   // passing in true forces the 
> destruction, yes a bit hacky... the OSG has a long history so can't recall 
> the circumstances of that addition...
>
> I will hold the 3.6.5 release back till we have some conclusion on this 
> issue, in case we need to make changes to the core OSG.
>
> Cheers,
> Robert.
>
 
Hi Robert,
Thank you for the help.
Manually clearing the registry fixed my crash on exit.
I will continue testing the next rc, so far so good.

Greetings,
Fabian

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/9062cb33-09fa-496a-8852-c7ffc1e826ac%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

[OpenSceneGraph Users]

Hi Robert,

That commit does indeed seem to have fixed my minimal reproducible example, 
and, unlike with my other minimal reproducible examples, it's fixed the 
issue with the OpenMW-CS, too. Thanks for getting that sorted.

Now I just have to remember what my favourite workaround for 3.4.1 was...

Cheers,

Chris

On Thursday, 30 January 2020 16:30:05 UTC, Robert Osfield wrote:
>
> Hi Chris et. al,
>
> On Thursday, 30 January 2020 14:39:08 UTC, OpenSceneGraph Users wrote:
>>
>> I slowly closing in on the cause of the Font issue, currently it looks 
>> like the removeView() is behaving differently form the CompositeViewer 
>> destructor and not handling clean up of contexts correctly.  I need to 
>> refactor how things are done internally, but expect to have a solution 
>> checked in this afternoon.
>>
>
> I have now checked a fix to the CompositeViewer::removeView() bug where GL 
> objects, including the Font, were not being cleaned up correctly.
>
>  
> https://github.com/openscenegraph/OpenSceneGraph/commit/25868955d2214139722806d20d2c4b60e32d4a61
>
> Cheers,
> Robert.
>

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/ef7190c6-6de8-4f0a-84be-4ffaefe30ecc%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

[OpenSceneGraph Users]

Hi Robert,
Compiling and a few simple runs worked fine, using
windows 10 Enterprise 1909 18363,592
Visual Studio 15.9.19
CMake 3.15.5
Regards, Laurens.

On Thu, Jan 30, 2020 at 5:30 PM OpenSceneGraph Users <
osg-users@lists.openscenegraph.org> wrote:

> Hi Chris et. al,
>
> On Thursday, 30 January 2020 14:39:08 UTC, OpenSceneGraph Users wrote:
>>
>> I slowly closing in on the cause of the Font issue, currently it looks
>> like the removeView() is behaving differently form the CompositeViewer
>> destructor and not handling clean up of contexts correctly.  I need to
>> refactor how things are done internally, but expect to have a solution
>> checked in this afternoon.
>>
>
> I have now checked a fix to the CompositeViewer::removeView() bug where GL
> objects, including the Font, were not being cleaned up correctly.
>
>
> https://github.com/openscenegraph/OpenSceneGraph/commit/25868955d2214139722806d20d2c4b60e32d4a61
>
> Cheers,
> Robert.
>
> --
> You received this message because you are subscribed to the Google Groups
> "OpenSceneGraph Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osg-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/osg-users/33fb547f-d61a-4c75-a3ec-e717ee1a6454%40googlegroups.com
> 
> .
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

[OpenSceneGraph Users]

Hi Chris et. al,

On Thursday, 30 January 2020 14:39:08 UTC, OpenSceneGraph Users wrote:
>
> I slowly closing in on the cause of the Font issue, currently it looks 
> like the removeView() is behaving differently form the CompositeViewer 
> destructor and not handling clean up of contexts correctly.  I need to 
> refactor how things are done internally, but expect to have a solution 
> checked in this afternoon.
>

I have now checked a fix to the CompositeViewer::removeView() bug where GL 
objects, including the Font, were not being cleaned up correctly.

 
https://github.com/openscenegraph/OpenSceneGraph/commit/25868955d2214139722806d20d2c4b60e32d4a61

Cheers,
Robert.

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/33fb547f-d61a-4c75-a3ec-e717ee1a6454%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

[OpenSceneGraph Users]

Hi Chris,

I slowly closing in on the cause of the Font issue, currently it looks like
the removeView() is behaving differently form the CompositeViewer
destructor and not handling clean up of contexts correctly.  I need to
refactor how things are done internally, but expect to have a solution
checked in this afternoon.

This fix might remove the issue with the static initialization by cleaning
up Font GL objects before the viewers are entirely destroyed and prior to
static clean up.

On Wed, 29 Jan 2020 at 22:21, OpenSceneGraph Users <
osg-users@lists.openscenegraph.org> wrote:

> Also, Robert, I'm assuming you don't have a copy of Morrowind to test
> OpenMW with. Right now, Steam, GreenManGaming and Fanatical are all
> offering it for less than £4, but at least one of those sales ends in less
> than twenty hours. If you're not keen, £4 is a reasonable investment for me
> to make to increase cooperation between our projects, but it would help if
> you got back to me quickly.
>

Thanks for the tip.  I am not a gamer these days, way too many other things
competing with my time.  I also have enough dev work that I really don't
want to get sucked into another open source project, there really are too
many projects that use the OSG for me to start providing direct support for
these projects beyond what I can provide through the OSG forum/mailing
list.  Please remember there is one of me vs many OSG users/projects.

Cheers,
Robert.

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/mailman.67741.1580395136.7167.osg-users-openscenegraph.org%40lists.openscenegraph.org.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/mailman.67741.1580395136.7167.osg-users-openscenegraph.org%40lists.openscenegraph.org.

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

[OpenSceneGraph Users]

Hi Robert,

I'm reasonably sure that Fabian's crash isn't the same issue as that 
example exposes.


>>- Fabian has done something weird with either OSG or OpenMW that 
>>hasn't been specified yet.
>>
>> If the codebase is the same perhaps it comes down to a sensitivity to 
> compiler version or dependencies?
>

We have official builds for a variety of Linux distros, Windows and MacOS 
(and semi-official builds for Android that are generally less reliable) so 
we should have pretty good coverage with known-good dependency and tooling 
versions. As I've mentioned before, the most likely culprit for this 
suddenly appearing for Fabian is that we pretty much never link to OSG 
statically. It's a nightmare on Windows (I don't think anyone's even 
attempted it in the last five years) but is more feasible on Linux, where 
the majority of our contributors are, so I've put out a call for other 
testers to try and reproduce the problem.



Also, Robert, I'm assuming you don't have a copy of Morrowind to test 
OpenMW with. Right now, Steam, GreenManGaming and Fanatical are all 
offering it for less than £4, but at least one of those sales ends in less 
than twenty hours. If you're not keen, £4 is a reasonable investment for me 
to make to increase cooperation between our projects, but it would help if 
you got back to me quickly.

Thanks,

Chris

On Wednesday, 29 January 2020 14:46:02 UTC, OpenSceneGraph Users wrote:
>
> Hi Chris,
>
> Thanks the links.  I've tracked down the example you created and re-run it 
> on my system and on the scene graph creation of the second window/view I 
> get text without textures.  
>
> In summary:
>>
>>- Fabian has done something weird with either OSG or OpenMW that 
>>hasn't been specified yet.
>>
>> If the codebase is the same perhaps it comes down to a sensitivity to 
> compiler version or dependencies?
>
>>
>>- It's beginning to feel like you're misspelling OpenMW deliberately.
>>
>> Sigh.  I likely have dyslexia, while I've never been formally diagnosed I 
> have the traits, the downside is that I regularily get letters wrong, don't 
> spot mispellings.  This isn't personal, it's just an issue I have to deal 
> with, and unfortunately as I read/wrote code and read/write email the 
> community also have to accept that I don't get everything right every 
> time.  In other ways my brain functions pretty well so overall I can still 
> be productive.
>
>
>>- Regarding the as-yet unresolved default font/object cache not being 
>>released issue I reported in March, the ball was left in your court with 
>>nothing more I could do. Hopefully enough has been linked above that we 
>> can 
>>move forward with that again if you've got more time now.
>>
>>
> If this is the one that the attached example recreates then I will be 
> looking into this today.
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/73cd3f2d-7a89-4ded-b247-e3586cea02ca%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

[OpenSceneGraph Users]

Hi Chris,

Thanks the links.  I've tracked down the example you created and re-run it
on my system and on the scene graph creation of the second window/view I
get text without textures.

In summary:
>
>- Fabian has done something weird with either OSG or OpenMW that
>hasn't been specified yet.
>
> If the codebase is the same perhaps it comes down to a sensitivity to
compiler version or dependencies?

>
>- It's beginning to feel like you're misspelling OpenMW deliberately.
>
> Sigh.  I likely have dyslexia, while I've never been formally diagnosed I
have the traits, the downside is that I regularily get letters wrong, don't
spot mispellings.  This isn't personal, it's just an issue I have to deal
with, and unfortunately as I read/wrote code and read/write email the
community also have to accept that I don't get everything right every
time.  In other ways my brain functions pretty well so overall I can still
be productive.


>- Regarding the as-yet unresolved default font/object cache not being
>released issue I reported in March, the ball was left in your court with
>nothing more I could do. Hopefully enough has been linked above that we can
>move forward with that again if you've got more time now.
>
>
If this is the one that the attached example recreates then I will be
looking into this today.

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/mailman.67380.1580309147.7166.osg-users-openscenegraph.org%40lists.openscenegraph.org.
cmake_minimum_required(VERSION 2.6)

SET(PROJECT_NAME viewtest)

PROJECT(${PROJECT_NAME})

FIND_PACKAGE(OpenThreads)
FIND_PACKAGE(osg)
FIND_PACKAGE(osgDB)
FIND_PACKAGE(osgUtil)
FIND_PACKAGE(osgGA)
FIND_PACKAGE(osgText)
FIND_PACKAGE(osgViewer)

SET(SOURCES
main.cpp
)

INCLUDE_DIRECTORIES(${OPENTHREADS_INCLUDE_DIR} ${OSG_INCLUDE_DIR})

LINK_DIRECTORIES(${OSG_LIB_DIR})

ADD_EXECUTABLE(${PROJECT_NAME} ${SOURCES})

TARGET_LINK_LIBRARIES(${PROJECT_NAME} ${OSG_LIBRARIES} ${OSGVIEWER_LIBRARIES} 
${OSGUTIL_LIBRARIES} ${OSGDB_LIBRARIES} ${OSGGA_LIBRARIES}  
${OSGTEXT_LIBRARIES} ${OPENTHREADS_LIBRARIES})
#include 

#include 

#include 

#include 

#include 

class AddViewOperation : public osg::Operation
{
public:
AddViewOperation(osg::ref_ptr view)
: osg::Operation("AddView", false)
, _view(view)
{}

void operator() (osg::Object * compositeViewer) override
{
OSG_NOTICE << "AddView operator()" << std::endl;
osgViewer::CompositeViewer * viewer = dynamic_cast(compositeViewer);
viewer->stopThreading();
viewer->addView(_view);
viewer->startThreading();
}

protected:
osg::ref_ptr _view;
};

class RemoveViewOperation : public osg::Operation
{
public:
RemoveViewOperation(osg::ref_ptr view)
: osg::Operation("RemoveView", false)
, _view(view)
{
OSG_NOTICE<<"RemoveViewOperation::RemoveViewOperation()"<(compositeViewer);
viewer->stopThreading();
viewer->removeView(_view);
viewer->startThreading();
}

protected:
osg::ref_ptr _view;
};

class ViewAdder : public osgGA::GUIEventHandler
{
public:
ViewAdder(osgViewer::CompositeViewer * viewer)
: _viewer(viewer)
, _view(nullptr)
{}

bool handle(const osgGA::GUIEventAdapter& ea, osgGA::GUIActionAdapter& aa)
{
if (ea.getEventType() == osgGA::GUIEventAdapter::KEYUP && (ea.getKey() == 'v' || ea.getKey() == 'V'))
{
if (_view)
{
OSG_NOTICE << "Existing view, remove it" << std::endl;
// parts of the scene get removed before the view gets destroyed.
// normally this is fine as things get handled by destructors.
// however, things that are still cached require the cache to be released
_view->setSceneData(nullptr);
// We need to remove the view after the event traversal is done to avoid invalidating iterators
_viewer->addUpdateOperation(new RemoveViewOperation(_view));
_view = nullptr;
}
else
{
OSG_NOTICE << "No existing view, create one" << std::endl;
_view = new osgViewer::View;
_view->setName("View two");

_view->setUpViewInWindow(800, 200, 1024, 768);


osg::ref_ptr text2 = new osgText::Text();
text2->setFont("times.ttf");
text2->setText("Here's some other text. It appears in the dynamically-added view. It ensures the default font gets used with a context that goes away, and that lives in the cache.");
osg::ref_ptr autoTransform2 = new osg::AutoTransform();
 

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

[OpenSceneGraph Users]

Hi Fabian,

On Wednesday, 29 January 2020 00:24:35 UTC, Fabian Roth wrote:
>
> Hi Chris,
> I am using the latest openmw master with the compatibility patch from the 
> pull request cherry picked, my build changes and minor other tweaks.
> I use the osg rc with a only a cmake version change.
> The branches are here:
> https://github.com/Eli2/openmw/tree/eli2-openmw-static
> https://github.com/Eli2/OpenSceneGraph/tree/eli2-openmw-static
>
> By now i strongly suspect i run into the "Static Initialization Order 
> Fiasco", as described here:
> https://cryptopp.com/wiki/Static_Initialization_Order_Fiasco
>
> I am currently looking into why my build uses the default font.
>

The way that the singleton methods are done is an attempt to resolve the 
construction order issue, but l don't recall a focus on the destruction 
side.  It could well be an issue.

One workaround might be to add a mutex directly to the Font objects that 
are being destructed rather than using the global one.  Or, to explicitly 
clear the ObjectCache on destruction rather than leaving it to static clean 
up.  The later would be my preferred approach.

A call to:

   osgDB::Registry::instance()->getObjectCache()->clear();

In application clean up should be sufficient, or force the destruction of 
the Registry singleton:

   osgDB::Registry::instance(true);   // passing in true forces the 
destruction, yes a bit hacky... the OSG has a long history so can't recall 
the circumstances of that addition...

I will hold the 3.6.5 release back till we have some conclusion on this 
issue, in case we need to make changes to the core OSG.

Cheers,
Robert.





 

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/dff4e0d7-343b-4893-bdeb-23e60528f42d%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

[OpenSceneGraph Users]

Hi Chris,
I am using the latest openmw master with the compatibility patch from the 
pull request cherry picked, my build changes and minor other tweaks.
I use the osg rc with a only a cmake version change.
The branches are here:
https://github.com/Eli2/openmw/tree/eli2-openmw-static
https://github.com/Eli2/OpenSceneGraph/tree/eli2-openmw-static

By now i strongly suspect i run into the "Static Initialization Order 
Fiasco", as described here:
https://cryptopp.com/wiki/Static_Initialization_Order_Fiasco

I am currently looking into why my build uses the default font.

Greetings,
Fabian

On Wednesday, January 29, 2020 at 12:34:20 AM UTC+1, Chris Djali / 
AnyOldName3 wrote:
>
> Hi Fabian,
>
> Link-time optimisation should be fine - we do it on release builds with no 
> problems. It's either something you've changed, or it's the static linking.
>
> We still don't know exactly which version of OpenMW and OSG you've built, 
> though. It's pretty obviously not the RC this thread is discussing if 
> you're using an existing OpenMW release or something you got from the 
> master branch with no local changes, as OpenMW literally won't build 
> without unofficial changes yet. Can you get back to us with a specific 
> answer?
>
> Cheers,
>
> Chris
>
> On Tuesday, 28 January 2020 23:13:47 UTC, Fabian Roth wrote:
>>
>>
>>
>> On Tuesday, January 28, 2020 at 10:11:49 AM UTC+1, OpenSceneGraph Users 
>> wrote:
>>>
>>> Hi Fabian,
>>>  
>>>
 My build is using static osg, static osg-plugins and link time 
 optimization.
 I created an address sanitizer enabled build.
 It exhibits a heap-use-after-free.
 I will try to further investigate this week.

 =
 ==11872==ERROR: AddressSanitizer: heap-use-after-free on address 
 0x603082c0 at pc 0x55b4b9659551 bp 0x7ffdf8a9c190 sp 0x7ffdf8a9c180
 READ of size 8 at 0x603082c0 thread T0
 #0 0x55b4b9659550 in 
 OpenThreads::ScopedPointerLock::ScopedPointerLock(OpenThreads::Mutex*)
  
 ./openmw/extern-git/OpenSceneGraph/include/OpenThreads/ScopedLock:54
 #1 0x55b4b9659550 in 
 osg::StateAttribute::removeParent(osg::StateSet*) 
 ./openmw/extern-git/OpenSceneGraph/src/osg/StateAttribute.cpp:38
 #2 0x55b4b965a033 in osg::StateSet::clear() 
 ./openmw/extern-git/OpenSceneGraph/src/osg/StateSet.cpp:734

>>>
>>> Given the stack trace it kinda looks like the getRefMutex() call in 
>>> StateAttribute.cpp is the where things might be going astray (note the 
>>> comment I've added below):
>>>
>>> void StateAttribute::removeParent(osg::StateSet* object)
>>> {
>>> OpenThreads::ScopedPointerLock 
>>> lock(getRefMutex()); // calls the base classes Referenced::getRefMutex() 
>>> method that will map to Referenced::getGlobalReferencedMutex
>>>
>>> ParentList::iterator pitr = 
>>> std::find(_parents.begin(),_parents.end(),object);
>>> if (pitr!=_parents.end()) _parents.erase(pitr);
>>> }
>>>
>>> The Referenced::getGlobalReferencedMutex() implementation in 
>>> Referenced.cpp is:
>>>
>>> OpenThreads::Mutex* Referenced::getGlobalReferencedMutex()
>>> {
>>> static GlobalMutexPointer s_ReferencedGlobalMutext = new 
>>> OpenThreads::Mutex;
>>> return s_ReferencedGlobalMutext.get();
>>> }
>>>
>>> // helper class for forcing the global mutex to be constructed when the 
>>> library is loaded.
>>> struct InitGlobalMutexes
>>> {
>>> InitGlobalMutexes()
>>> {
>>> Referenced::getGlobalReferencedMutex();
>>> }
>>> };
>>> static InitGlobalMutexes s_initGlobalMutexes;
>>>
>>> Which is all a bit hacky way of trying to get a singleton's 
>>> _ReferencedGlobalMutext to construct before any other code calling 
>>> getGlobalReferencedMutex() gets called.
>>>
>>> I don't really know why a pointer is even being used here, it's not how 
>>> I'd write the code these days, but off the top of my head don't recall the 
>>> derivation and motivations between all this code as it dates back to the 
>>> earliest days of the OSG project, so almost two decades :-)
>>>
>>> What I'd write today would simply be:
>>>
>>> static OpenThreads::Mutex s_ReferencedGlobalMutex;
>>> OpenThreads::Mutex* Referenced::getGlobalReferencedMutex()
>>> {
>>> return _ReferencedGlobalMutex;
>>> }
>>>
>>> You could try substituting this in.  I will try a build here just to 
>>> make sure the above works fine for standard OSG work.  I don't expect this 
>>> change to have any affect on your own code, if it does it suggest there is 
>>> some issue with order of clean up of statics.
>>>
>>> Robert.
>>>
>>
>> Hi Robert,
>> Using your suggested changes i get a crash on start.
>> I forgot to mention i also link OpenThreads statically.
>> I am starting to suspect the static linking and optimization surfaces 
>> undefined behavior.
>>
>> Greetings,
>> Fabian
>>
>> ASAN:DEADLYSIGNAL
>> =
>> 

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

[OpenSceneGraph Users]

Hi Fabian,

Link-time optimisation should be fine - we do it on release builds with no 
problems. It's either something you've changed, or it's the static linking.

We still don't know exactly which version of OpenMW and OSG you've built, 
though. It's pretty obviously not the RC this thread is discussing if 
you're using an existing OpenMW release or something you got from the 
master branch with no local changes, as OpenMW literally won't build 
without unofficial changes yet. Can you get back to us with a specific 
answer?

Cheers,

Chris

On Tuesday, 28 January 2020 23:13:47 UTC, Fabian Roth wrote:
>
>
>
> On Tuesday, January 28, 2020 at 10:11:49 AM UTC+1, OpenSceneGraph Users 
> wrote:
>>
>> Hi Fabian,
>>  
>>
>>> My build is using static osg, static osg-plugins and link time 
>>> optimization.
>>> I created an address sanitizer enabled build.
>>> It exhibits a heap-use-after-free.
>>> I will try to further investigate this week.
>>>
>>> =
>>> ==11872==ERROR: AddressSanitizer: heap-use-after-free on address 
>>> 0x603082c0 at pc 0x55b4b9659551 bp 0x7ffdf8a9c190 sp 0x7ffdf8a9c180
>>> READ of size 8 at 0x603082c0 thread T0
>>> #0 0x55b4b9659550 in 
>>> OpenThreads::ScopedPointerLock::ScopedPointerLock(OpenThreads::Mutex*)
>>>  
>>> ./openmw/extern-git/OpenSceneGraph/include/OpenThreads/ScopedLock:54
>>> #1 0x55b4b9659550 in 
>>> osg::StateAttribute::removeParent(osg::StateSet*) 
>>> ./openmw/extern-git/OpenSceneGraph/src/osg/StateAttribute.cpp:38
>>> #2 0x55b4b965a033 in osg::StateSet::clear() 
>>> ./openmw/extern-git/OpenSceneGraph/src/osg/StateSet.cpp:734
>>>
>>
>> Given the stack trace it kinda looks like the getRefMutex() call in 
>> StateAttribute.cpp is the where things might be going astray (note the 
>> comment I've added below):
>>
>> void StateAttribute::removeParent(osg::StateSet* object)
>> {
>> OpenThreads::ScopedPointerLock 
>> lock(getRefMutex()); // calls the base classes Referenced::getRefMutex() 
>> method that will map to Referenced::getGlobalReferencedMutex
>>
>> ParentList::iterator pitr = 
>> std::find(_parents.begin(),_parents.end(),object);
>> if (pitr!=_parents.end()) _parents.erase(pitr);
>> }
>>
>> The Referenced::getGlobalReferencedMutex() implementation in 
>> Referenced.cpp is:
>>
>> OpenThreads::Mutex* Referenced::getGlobalReferencedMutex()
>> {
>> static GlobalMutexPointer s_ReferencedGlobalMutext = new 
>> OpenThreads::Mutex;
>> return s_ReferencedGlobalMutext.get();
>> }
>>
>> // helper class for forcing the global mutex to be constructed when the 
>> library is loaded.
>> struct InitGlobalMutexes
>> {
>> InitGlobalMutexes()
>> {
>> Referenced::getGlobalReferencedMutex();
>> }
>> };
>> static InitGlobalMutexes s_initGlobalMutexes;
>>
>> Which is all a bit hacky way of trying to get a singleton's 
>> _ReferencedGlobalMutext to construct before any other code calling 
>> getGlobalReferencedMutex() gets called.
>>
>> I don't really know why a pointer is even being used here, it's not how 
>> I'd write the code these days, but off the top of my head don't recall the 
>> derivation and motivations between all this code as it dates back to the 
>> earliest days of the OSG project, so almost two decades :-)
>>
>> What I'd write today would simply be:
>>
>> static OpenThreads::Mutex s_ReferencedGlobalMutex;
>> OpenThreads::Mutex* Referenced::getGlobalReferencedMutex()
>> {
>> return _ReferencedGlobalMutex;
>> }
>>
>> You could try substituting this in.  I will try a build here just to make 
>> sure the above works fine for standard OSG work.  I don't expect this 
>> change to have any affect on your own code, if it does it suggest there is 
>> some issue with order of clean up of statics.
>>
>> Robert.
>>
>
> Hi Robert,
> Using your suggested changes i get a crash on start.
> I forgot to mention i also link OpenThreads statically.
> I am starting to suspect the static linking and optimization surfaces 
> undefined behavior.
>
> Greetings,
> Fabian
>
> ASAN:DEADLYSIGNAL
> =
> ==19668==ERROR: AddressSanitizer: SEGV on unknown address 0x0010 
> (pc 0x5597ebadb5ac bp 0x60c00b80 sp 0x7ffce8efbba0 T0)
> ==19668==The signal is caused by a READ memory access.
> ==19668==Hint: address points to the zero page.
> #0 0x5597ebadb5ab in 
> OpenThreads::ScopedPointerLock::ScopedPointerLock(OpenThreads::Mutex*)
>  
> ./openmw/extern-git/OpenSceneGraph/include/OpenThreads/ScopedLock:54
> #1 0x5597ebadb5ab in addParent 
> ./openmw/extern-git/OpenSceneGraph/src/osg/StateAttribute.cpp:31
> #2 0x5597ebadbc84 in setAttribute 
> ./openmw/extern-git/OpenSceneGraph/src/osg/StateSet.cpp:1784
> #3 0x5597ebadc737 in 
> osg::StateSet::setAttributeAndModes(osg::StateAttribute*, unsigned int) 
> [clone .part.309] 
> ./openmw/extern-git/OpenSceneGraph/src/osg/StateSet.cpp:1076
> #4 

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

[OpenSceneGraph Users]

On Tuesday, January 28, 2020 at 10:11:49 AM UTC+1, OpenSceneGraph Users 
wrote:
>
> Hi Fabian,
>  
>
>> My build is using static osg, static osg-plugins and link time 
>> optimization.
>> I created an address sanitizer enabled build.
>> It exhibits a heap-use-after-free.
>> I will try to further investigate this week.
>>
>> =
>> ==11872==ERROR: AddressSanitizer: heap-use-after-free on address 
>> 0x603082c0 at pc 0x55b4b9659551 bp 0x7ffdf8a9c190 sp 0x7ffdf8a9c180
>> READ of size 8 at 0x603082c0 thread T0
>> #0 0x55b4b9659550 in 
>> OpenThreads::ScopedPointerLock::ScopedPointerLock(OpenThreads::Mutex*)
>>  
>> ./openmw/extern-git/OpenSceneGraph/include/OpenThreads/ScopedLock:54
>> #1 0x55b4b9659550 in 
>> osg::StateAttribute::removeParent(osg::StateSet*) 
>> ./openmw/extern-git/OpenSceneGraph/src/osg/StateAttribute.cpp:38
>> #2 0x55b4b965a033 in osg::StateSet::clear() 
>> ./openmw/extern-git/OpenSceneGraph/src/osg/StateSet.cpp:734
>>
>
> Given the stack trace it kinda looks like the getRefMutex() call in 
> StateAttribute.cpp is the where things might be going astray (note the 
> comment I've added below):
>
> void StateAttribute::removeParent(osg::StateSet* object)
> {
> OpenThreads::ScopedPointerLock 
> lock(getRefMutex()); // calls the base classes Referenced::getRefMutex() 
> method that will map to Referenced::getGlobalReferencedMutex
>
> ParentList::iterator pitr = 
> std::find(_parents.begin(),_parents.end(),object);
> if (pitr!=_parents.end()) _parents.erase(pitr);
> }
>
> The Referenced::getGlobalReferencedMutex() implementation in 
> Referenced.cpp is:
>
> OpenThreads::Mutex* Referenced::getGlobalReferencedMutex()
> {
> static GlobalMutexPointer s_ReferencedGlobalMutext = new 
> OpenThreads::Mutex;
> return s_ReferencedGlobalMutext.get();
> }
>
> // helper class for forcing the global mutex to be constructed when the 
> library is loaded.
> struct InitGlobalMutexes
> {
> InitGlobalMutexes()
> {
> Referenced::getGlobalReferencedMutex();
> }
> };
> static InitGlobalMutexes s_initGlobalMutexes;
>
> Which is all a bit hacky way of trying to get a singleton's 
> _ReferencedGlobalMutext to construct before any other code calling 
> getGlobalReferencedMutex() gets called.
>
> I don't really know why a pointer is even being used here, it's not how 
> I'd write the code these days, but off the top of my head don't recall the 
> derivation and motivations between all this code as it dates back to the 
> earliest days of the OSG project, so almost two decades :-)
>
> What I'd write today would simply be:
>
> static OpenThreads::Mutex s_ReferencedGlobalMutex;
> OpenThreads::Mutex* Referenced::getGlobalReferencedMutex()
> {
> return _ReferencedGlobalMutex;
> }
>
> You could try substituting this in.  I will try a build here just to make 
> sure the above works fine for standard OSG work.  I don't expect this 
> change to have any affect on your own code, if it does it suggest there is 
> some issue with order of clean up of statics.
>
> Robert.
>

Hi Robert,
Using your suggested changes i get a crash on start.
I forgot to mention i also link OpenThreads statically.
I am starting to suspect the static linking and optimization surfaces 
undefined behavior.

Greetings,
Fabian

ASAN:DEADLYSIGNAL
=
==19668==ERROR: AddressSanitizer: SEGV on unknown address 0x0010 
(pc 0x5597ebadb5ac bp 0x60c00b80 sp 0x7ffce8efbba0 T0)
==19668==The signal is caused by a READ memory access.
==19668==Hint: address points to the zero page.
#0 0x5597ebadb5ab in 
OpenThreads::ScopedPointerLock::ScopedPointerLock(OpenThreads::Mutex*)
 
./openmw/extern-git/OpenSceneGraph/include/OpenThreads/ScopedLock:54
#1 0x5597ebadb5ab in addParent 
./openmw/extern-git/OpenSceneGraph/src/osg/StateAttribute.cpp:31
#2 0x5597ebadbc84 in setAttribute 
./openmw/extern-git/OpenSceneGraph/src/osg/StateSet.cpp:1784
#3 0x5597ebadc737 in 
osg::StateSet::setAttributeAndModes(osg::StateAttribute*, unsigned int) 
[clone .part.309] 
./openmw/extern-git/OpenSceneGraph/src/osg/StateSet.cpp:1076
#4 0x5597ebcb7241 in __base_ctor  
./openmw/extern-git/OpenSceneGraph/src/osgUtil/RenderBin.cpp:174
#5 0x5597ebcb7a37 in __base_ctor  
./openmw/extern-git/OpenSceneGraph/src/osgUtil/RenderBin.cpp:37
#6 0x5597ebcb7a37 in renderBinPrototypeList 
./openmw/extern-git/OpenSceneGraph/src/osgUtil/RenderBin.cpp:53
#7 0x5597eab5bacb in RenderBinSingletonProxy::RenderBinSingletonProxy() 
./openmw/extern-git/OpenSceneGraph/src/osgUtil/RenderBin.cpp:58
#8 0x5597eab5bacb in __static_initialization_and_destruction_0 
./openmw/extern-git/OpenSceneGraph/src/osgUtil/RenderBin.cpp:58
#9 0x5597eab5bacb in 
_GLOBAL__sub_I__ZN7osgUtil9RenderBin21getRenderBinPrototypeERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE.lto_priv.3181
 

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

[OpenSceneGraph Users]

Hello again.

The googlegroup has search options, here's what I get if I search for 
> OpenMW. it comes up with several threads with you contributing:
>
> https://groups.google.com/forum/#!searchin/osg-users/OpenMW%7Csort:date
>

I can find chunks of the right thread (this is some: 
https://groups.google.com/forum/#!searchin/osg-users/OpenMW|sort:date/osg-users/4lwB0MZdPqM/-ohFXtp-CQAJ)
 
but some seems to be missing. For example, this newer chunk shows up as a 
separate thread: 
https://groups.google.com/forum/#!searchin/osg-users/anyoldname3|sort:date/osg-users/lbFxUItJ_qc/KEkYK_1dAgAJ.
 
It's reasonably likely that that's the end of the thread.

I don't disappear completely, I just step back.
>

I'm aware of the reasoning and that it's not total. It still has a pretty 
big impact on how much OSG work you actually get done, so I feel my word 
choice isn't that extreme.

If you have things you feel would be suitable to merge with the 3.6 branch 
> please make them. I can't review and provide feedback.  To properly judge 
> changes I do need to understand the motivation behind them, it may be that 
> the changes are workaround issues that are based solved in other ways.
>

https://groups.google.com/d/msg/osg-users/lbFxUItJ_qc/c54xoN8oAAAJ has a 
diff that resolved my problem and I suggested went into 3.6. A few posts 
lower, there's what we both agreed was the source for a simple application 
that didn't work. You said you'd look into it in more detail later in the 
hope of finding other potential solutions. I can't do that for you. I put 
days into this and couldn't find any better solutions than the one I 
posted. That might have been because I didn't write OSG and am unaware of a 
nifty feature that will fix everything, because I'm not actually clever 
enough to conceive of the right approach, or because there's genuinely no 
other option. It's certainly not because I didn't do a thorough enough 
investigation.

When you say not seeing the crash, I we talking about a different issue to 
> what Fabian was referring to?  Is Fabian working on the same versions of 
> OpenME and OSG as yourself?
>

I was referring to the crash he was seeing with the profiler. It's still 
called *OpenMW* with one *O* and one *W*, by the way. My testing was with 
the 3.6 branch of OSG as of 9b41f260 and master branch OpenMW from a few 
weeks ago. I've also got minor local changes to adapt to the Julien 
Valentine occlusion query PR you merged recently. Nothing that touches 
anything relevant to Fabian's crash has been merged since then, so latest 
master branch OpenMW is a good analogue for what I'm using. I suspect 
Fabian isn't using the same OSG and OpenMW as me exactly, as he needs to 
either merge this https://github.com/OpenMW/openmw/pull/2676 (or something 
like it) or use an OSG revision from before this 
https://github.com/openscenegraph/OpenSceneGraph/pull/902 got merged.

The OSG falls back to using the DefaultFont when the requested font can't 
> be found, so any chance this might be happening?  Something like font files 
> missing, case of the font being different - Windows isn't case sensitive so 
> when you move to a case sensitive OS you can see issues if there are errors 
> in the filename.
>

I've checked, and we switched to using a bundled TTF font in the middle of 
2018. Most development happens on Linux (and the person who switched the 
font over uses it exclusively) so the only way it wouldn't be finding the 
font would be if Fabian's doing something weird.

My build is using static osg, static osg-plugins and link time optimization.
>

For example, this could be the weird thing. We don't test statically linked 
OSG, although our semi-official Android port does things that way (it's not 
maintained by the core team, just one guy on his own, and it's got plenty 
of shortcomings). One possibility is that the Freetype plugin just got left 
out when building. Renaming the DLL so OpenMW couldn't see it did make it 
use the OSG default font in the profiler, but didn't allow me to reproduce 
Fabian's crash.



In summary:

   - Fabian has done something weird with either OSG or OpenMW that hasn't 
   been specified yet.
   - It's beginning to feel like you're misspelling OpenMW deliberately.
   - Regarding the as-yet unresolved default font/object cache not being 
   released issue I reported in March, the ball was left in your court with 
   nothing more I could do. Hopefully enough has been linked above that we can 
   move forward with that again if you've got more time now.
   - Without knowing what source code Fabian has built, I can't reproduce 
   or identify the issue he's seeing.

Cheers,

Chris





On Tuesday, 28 January 2020 11:51:31 UTC, OpenSceneGraph Users wrote:
>
> Hi Fabian & Chris,
>
> I was curious about the clean up of the global getGlobalReferencedMutex() 
> so I added some debug messages to OpenThreads and to relevant calls in the 
> OSG to track the creation and clean up of mutexes.  I 

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

[OpenSceneGraph Users]

Hi Fabian & Chris,

I was curious about the clean up of the global getGlobalReferencedMutex()
so I added some debug messages to OpenThreads and to relevant calls in the
OSG to track the creation and clean up of mutexes.  I tried an alternative
means of static initialization of the static getGlobalReferencedMutex() and
got the same behavior for before and after results so I don't think the
version in the 3.6 branch is likley to be be a source of problem, even if
it's not particular clean.  Below is diff of the changes I made.

Robert

$ git diff
diff --git a/src/OpenThreads/pthreads/PThreadMutex.cpp
b/src/OpenThreads/pthreads/PThreadMutex.cpp
index 3a3d1c338..d122fc67c 100644
--- a/src/OpenThreads/pthreads/PThreadMutex.cpp
+++ b/src/OpenThreads/pthreads/PThreadMutex.cpp
@@ -22,6 +22,8 @@
 #include 
 #include "PThreadMutexPrivateData.h"

+#include 
+
 using namespace OpenThreads;

 //
@@ -33,7 +35,7 @@ using namespace OpenThreads;
 Mutex::Mutex(MutexType type):
 _mutexType(type)
 {
-
+printf("Mutex::Mutex(%d) %p\n", type, this);
 pthread_mutexattr_t mutex_attr;
 pthread_mutexattr_init( _attr );

@@ -107,6 +109,8 @@ Mutex::Mutex(MutexType type):
 //
 Mutex::~Mutex() {

+printf("Mutex::~Mutex() %p\n", this);
+
 PThreadMutexPrivateData *pd =
 static_cast(_prvData);

diff --git a/src/osg/Referenced.cpp b/src/osg/Referenced.cpp
index 95b665c57..267bda310 100644
--- a/src/osg/Referenced.cpp
+++ b/src/osg/Referenced.cpp
@@ -79,11 +79,16 @@ struct ResetPointer
 };

 typedef ResetPointer DeleteHandlerPointer;
+
+#if 1
+#include 
+
 typedef ResetPointer GlobalMutexPointer;

 OpenThreads::Mutex* Referenced::getGlobalReferencedMutex()
 {
 static GlobalMutexPointer s_ReferencedGlobalMutext = new
OpenThreads::Mutex;
+printf("Referenced::getGlobalReferencedMutex() %p\n",
(s_ReferencedGlobalMutext.get()));
 return s_ReferencedGlobalMutext.get();
 }

@@ -96,6 +101,17 @@ struct InitGlobalMutexes
 }
 };
 static InitGlobalMutexes s_initGlobalMutexes;
+#else
+
+#include 
+
+static OpenThreads::Mutex s_ReferencedGlobalMutex;
+OpenThreads::Mutex* Referenced::getGlobalReferencedMutex()
+{
+printf("Referenced::getGlobalReferencedMutex() %p\n",
(_ReferencedGlobalMutex));
+return _ReferencedGlobalMutex;
+}
+#endif

 // static std::auto_ptr s_deleteHandler(0);
 static DeleteHandlerPointer s_deleteHandler(0);
diff --git a/src/osg/StateAttribute.cpp b/src/osg/StateAttribute.cpp
index e239fb3aa..c7df40894 100644
--- a/src/osg/StateAttribute.cpp
+++ b/src/osg/StateAttribute.cpp
@@ -39,6 +39,8 @@ void StateAttribute::removeParent(osg::StateSet* object)

 ParentList::iterator pitr =
std::find(_parents.begin(),_parents.end(),object);
 if (pitr!=_parents.end()) _parents.erase(pitr);
+
+printf("StateAttribute::removeParent()\n");
 }
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

[OpenSceneGraph Users]

Hi Fabian,


> My build is using static osg, static osg-plugins and link time
> optimization.
> I created an address sanitizer enabled build.
> It exhibits a heap-use-after-free.
> I will try to further investigate this week.
>
> =
> ==11872==ERROR: AddressSanitizer: heap-use-after-free on address
> 0x603082c0 at pc 0x55b4b9659551 bp 0x7ffdf8a9c190 sp 0x7ffdf8a9c180
> READ of size 8 at 0x603082c0 thread T0
> #0 0x55b4b9659550 in
> OpenThreads::ScopedPointerLock::ScopedPointerLock(OpenThreads::Mutex*)
> ./openmw/extern-git/OpenSceneGraph/include/OpenThreads/ScopedLock:54
> #1 0x55b4b9659550 in osg::StateAttribute::removeParent(osg::StateSet*)
> ./openmw/extern-git/OpenSceneGraph/src/osg/StateAttribute.cpp:38
> #2 0x55b4b965a033 in osg::StateSet::clear()
> ./openmw/extern-git/OpenSceneGraph/src/osg/StateSet.cpp:734
>

Given the stack trace it kinda looks like the getRefMutex() call in
StateAttribute.cpp is the where things might be going astray (note the
comment I've added below):

void StateAttribute::removeParent(osg::StateSet* object)
{
OpenThreads::ScopedPointerLock lock(getRefMutex());
// calls the base classes Referenced::getRefMutex() method that will map to
Referenced::getGlobalReferencedMutex

ParentList::iterator pitr =
std::find(_parents.begin(),_parents.end(),object);
if (pitr!=_parents.end()) _parents.erase(pitr);
}

The Referenced::getGlobalReferencedMutex() implementation in Referenced.cpp
is:

OpenThreads::Mutex* Referenced::getGlobalReferencedMutex()
{
static GlobalMutexPointer s_ReferencedGlobalMutext = new
OpenThreads::Mutex;
return s_ReferencedGlobalMutext.get();
}

// helper class for forcing the global mutex to be constructed when the
library is loaded.
struct InitGlobalMutexes
{
InitGlobalMutexes()
{
Referenced::getGlobalReferencedMutex();
}
};
static InitGlobalMutexes s_initGlobalMutexes;

Which is all a bit hacky way of trying to get a singleton's
_ReferencedGlobalMutext to construct before any other code calling
getGlobalReferencedMutex() gets called.

I don't really know why a pointer is even being used here, it's not how I'd
write the code these days, but off the top of my head don't recall the
derivation and motivations between all this code as it dates back to the
earliest days of the OSG project, so almost two decades :-)

What I'd write today would simply be:

static OpenThreads::Mutex s_ReferencedGlobalMutex;
OpenThreads::Mutex* Referenced::getGlobalReferencedMutex()
{
return _ReferencedGlobalMutex;
}

You could try substituting this in.  I will try a build here just to make
sure the above works fine for standard OSG work.  I don't expect this
change to have any affect on your own code, if it does it suggest there is
some issue with order of clean up of statics.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

[OpenSceneGraph Users]

Hi Chris,

On Mon, 27 Jan 2020 at 23:51, OpenSceneGraph Users <
osg-users@lists.openscenegraph.org> wrote:

> As I've mentioned in the past, I'm an OpenMW (note the single M)
> developer. It was actually me who reported the issues with the default
> font, and only a subset were resolved before you went on hiatus. I've lost
> the thread where we were discussing it as I'd bookmarked the forum thread,
> which is now dead. As I recall, though, my most recent minimal
> things-don't-get-relased-when-they-should example was resolvable by a
> couple of potential changes I suggested, but you said they'd have to wait
> until you could investigate more thoroughly, as it was in code no one had
> touched for a while, so could maybe upset other applications, or not
> exhaustively remove all such bugs.
>

The googlegroup has search options, here's what I get if I search for
OpenMW. it comes up with several threads with you contributing:

https://groups.google.com/forum/#!searchin/osg-users/OpenMW%7Csort:date


> I pretty much stopped trying to make OpenMW play nicely with 3.6.x when
> you disappeared as there wasn't much point if nothing would be mergeable
> until you had more time, and now you do, I don't have much.
>

I had to step back from the OSG support side as it consumes so much time
and mind-share, it's not really possible to tackle other complex work at
the same time so I'm having to block the OSG support side and not tackle
any complex other work during this period. I don't disappear completely, I
just step back.

Anyway, on to the matter at hand, I don't get the crash, but I'm missing
> some commits in the 3.6 branch, and also I still have one of my proposed
> fixes. I'm making things more upstream-like, and I'll add another sentence
> once everything's rebuilt.
>

If you have things you feel would be suitable to merge with the 3.6 branch
please make them. I can't review and provide feedback.  To properly judge
changes I do need to understand the motivation behind them, it may be that
the changes are workaround issues that are based solved in other ways.


> So after waiting an age for everything to rebuild, I got reminded that the
> occlusion query API got changed by Julien Valentine's recent PR. He made a
> PR for OpenMW that was supposed to resolve that, but obviously it didn't
> work until I tweaked it. Once I'd built everything, I tested it, and I'm
> not seeing the crash here. This is with a Debug build of OpenMW and OSG,
> and on Windows, and I don't think anyone else is using debug builds of
> both, especially not on Windows.
>

When you say not seeing the crash, I we talking about a different issue to
what Fabian was referring to?  Is Fabian working on the same versions of
OpenME and OSG as yourself?

I guess that means that I've not really given any more information beyond
> this not being something that happens for everyone. It might be dependent
> on other factors, so a more detailed description of how reliable the crash
> is and whether it's dependent on anything is needed before anyone can do
> anything on OpenMW's end.
>
> One thing of note is that the OpenMW profiler doesn't use the default font
> (at least on my machine). It uses a truetype one. I seem to remember seeing
> it use the default font in the past, and it's not impossible that this is
> toggled via a setting I've forgotten about, but I've had a good look and
> can't find one.
>

The OSG falls back to using the DefaultFont when the requested font can't
be found, so any chance this might be happening?  Something like font files
missing, case of the font being different - Windows isn't case sensitive so
when you move to a case sensitive OS you can see issues if there are errors
in the filename.

Cheers,
Robert.

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/mailman.67301.1580201727.7167.osg-users-openscenegraph.org%40lists.openscenegraph.org.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/mailman.67301.1580201727.7167.osg-users-openscenegraph.org%40lists.openscenegraph.org.

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

[OpenSceneGraph Users]

Am Montag, 27. Januar 2020 10:57:23 UTC+1 schrieb Robert Osfield:
>
> Hi Fiabian,
>
> On Monday, 27 January 2020 09:41:43 UTC, Fabian Roth wrote:
>>
>> Hi,
>> I am currently testing this RC with openmw.
>> If i have the fps display or profiler open while exiting the application 
>> i get a crash on exit.
>> I am not sure if this is due to a bug in my build, a bug in openmw or a 
>> real issue with osg.
>> The issue seems to be related to the destruction of the default font, but 
>> i was not able to investigate further.
>> Attached is a Backtrace of the issue i am currently observing.
>>
>
> That stack trace looks like the automatic clean up of the ObjectCache with 
> the DefaultFont within it is related somehow to the crash.  How the 
> DefaultFont is managed has changed, to address bugs ironically, and in a 
> general sense the clean up the stack trace looks just fine to me, it's 
> roughly what I'd expect to happen.  However, I don't have any clear idea 
> why in this instance the crash has occurred.
>
> Given there isn't any obvious amiss we are unfortunately are left to widen 
> out the search for what is amiss. 
>
> Does running an OSG example like osgtext fail?
>
> Do others in the OpenMMW community seen this same crash?
>
> Is it possible to run OpenMMW single threaded to see if there might be 
> some thread interaction?
>
> What OS/compile and OpenMMW version combination are you using?
>
> One possible cause of crash like this is memory corruption during the run 
> of the application that is only revealed on clean up.  Using a memory tools 
> like valgrind might be spot this type of issue.
>
> Perhaps others might have seen something similar and can help shed some 
> light on the nature of the crash.
>
> If it's possible to recreate the crash with an standard OSG example, or a 
> small modification of one, then this would be really helpful for me to jump 
> in a start investigating the issue.
>
> Cheers.
> Robert.
>
 
Hi,
Thank you for the fast reply.
My build is using static osg, static osg-plugins and link time optimization.
I created an address sanitizer enabled build.
It exhibits a heap-use-after-free.
I will try to further investigate this week.

Greetings,
Fabian


=
==11872==ERROR: AddressSanitizer: heap-use-after-free on address 
0x603082c0 at pc 0x55b4b9659551 bp 0x7ffdf8a9c190 sp 0x7ffdf8a9c180
READ of size 8 at 0x603082c0 thread T0
#0 0x55b4b9659550 in 
OpenThreads::ScopedPointerLock::ScopedPointerLock(OpenThreads::Mutex*)
 
./openmw/extern-git/OpenSceneGraph/include/OpenThreads/ScopedLock:54
#1 0x55b4b9659550 in osg::StateAttribute::removeParent(osg::StateSet*) 
./openmw/extern-git/OpenSceneGraph/src/osg/StateAttribute.cpp:38
#2 0x55b4b965a033 in osg::StateSet::clear() 
./openmw/extern-git/OpenSceneGraph/src/osg/StateSet.cpp:734
#3 0x55b4b965a5ef in __base_dtor  
./openmw/extern-git/OpenSceneGraph/src/osg/StateSet.cpp:285
#4 0x55b4b965a9f8 in __deleting_dtor  
./openmw/extern-git/OpenSceneGraph/src/osg/StateSet.cpp:286
#5 0x55b4b9c98246 in osg::Referenced::unref() const 
./openmw/extern-git/OpenSceneGraph/include/osg/Referenced:201
#6 0x55b4b9c98246 in osg::ref_ptr::~ref_ptr() 
./openmw/extern-git/OpenSceneGraph/include/osg/ref_ptr:41
#7 0x55b4b9c98246 in void std::_Destroy 
>(osg::ref_ptr*) /usr/include/c++/7/bits/stl_construct.h:98
#8 0x55b4b9c98246 in void 
std::_Destroy_aux::__destroy*>(osg::ref_ptr*,
 
osg::ref_ptr*) /usr/include/c++/7/bits/stl_construct.h:108
#9 0x55b4b9c98246 in void 
std::_Destroy*>(osg::ref_ptr*, 
osg::ref_ptr*) /usr/include/c++/7/bits/stl_construct.h:137
#10 0x55b4b9c98246 in void std::_Destroy*, 
osg::ref_ptr >(osg::ref_ptr*, 
osg::ref_ptr*, std::allocator 
>&) /usr/include/c++/7/bits/stl_construct.h:206
#11 0x55b4b9c98246 in std::vector, 
std::allocator > >::~vector() [clone 
.lto_priv.5218] /usr/include/c++/7/bits/stl_vector.h:434
#12 0x55b4b9da20dd in osgText::Font::~Font() 
./openmw/extern-git/OpenSceneGraph/src/osgText/Font.cpp:295
#13 0x55b4b9e59ed2 in __base_dtor  
./openmw/extern-git/OpenSceneGraph/src/osgText/DefaultFont.cpp:35
#14 0x55b4b9e59ed2 in __deleting_dtor  
./openmw/extern-git/OpenSceneGraph/src/osgText/DefaultFont.cpp:37
#15 0x55b4b8df93d6 in osg::Referenced::unref() const 
./openmw/extern-git/OpenSceneGraph/include/osg/Referenced:201
#16 0x55b4b98e7518 in osg::ref_ptr::~ref_ptr() 
./openmw/extern-git/OpenSceneGraph/include/osg/ref_ptr:41
#17 0x55b4b98e7518 in std::pair, 
double>::~pair() /usr/include/c++/7/bits/stl_pair.h:208
#18 0x55b4b98e7518 in __base_dtor  
/usr/include/c++/7/bits/stl_pair.h:208
#19 0x55b4b98e7518 in void 
__gnu_cxx::new_allocator, std::allocator >, osg::ref_ptr > const, std::pair, double> > > 
>::destroy, std::allocator >, osg::ref_ptr > const, std::pair, double> > 
>(std::pair, std::allocator >, osg::ref_ptr > const, std::pair, double> >*) 

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

[OpenSceneGraph Users]

Hi Robert,

As I've mentioned in the past, I'm an OpenMW (note the single M) developer. 
It was actually me who reported the issues with the default font, and only 
a subset were resolved before you went on hiatus. I've lost the thread 
where we were discussing it as I'd bookmarked the forum thread, which is 
now dead. As I recall, though, my most recent minimal 
things-don't-get-relased-when-they-should example was resolvable by a 
couple of potential changes I suggested, but you said they'd have to wait 
until you could investigate more thoroughly, as it was in code no one had 
touched for a while, so could maybe upset other applications, or not 
exhaustively remove all such bugs.

I pretty much stopped trying to make OpenMW play nicely with 3.6.x when you 
disappeared as there wasn't much point if nothing would be mergeable until 
you had more time, and now you do, I don't have much.

Anyway, on to the matter at hand, I don't get the crash, but I'm missing 
some commits in the 3.6 branch, and also I still have one of my proposed 
fixes. I'm making things more upstream-like, and I'll add another sentence 
once everything's rebuilt.

So after waiting an age for everything to rebuild, I got reminded that the 
occlusion query API got changed by Julien Valentine's recent PR. He made a 
PR for OpenMW that was supposed to resolve that, but obviously it didn't 
work until I tweaked it. Once I'd built everything, I tested it, and I'm 
not seeing the crash here. This is with a Debug build of OpenMW and OSG, 
and on Windows, and I don't think anyone else is using debug builds of 
both, especially not on Windows.

I guess that means that I've not really given any more information beyond 
this not being something that happens for everyone. It might be dependent 
on other factors, so a more detailed description of how reliable the crash 
is and whether it's dependent on anything is needed before anyone can do 
anything on OpenMW's end.



One thing of note is that the OpenMW profiler doesn't use the default font 
(at least on my machine). It uses a truetype one. I seem to remember seeing 
it use the default font in the past, and it's not impossible that this is 
toggled via a setting I've forgotten about, but I've had a good look and 
can't find one.

So that's what I know.

Chris

On Monday, 27 January 2020 09:57:23 UTC, Robert Osfield wrote:
>
> Hi Fiabian,
>
> On Monday, 27 January 2020 09:41:43 UTC, Fabian Roth wrote:
>>
>> Hi,
>> I am currently testing this RC with openmw.
>> If i have the fps display or profiler open while exiting the application 
>> i get a crash on exit.
>> I am not sure if this is due to a bug in my build, a bug in openmw or a 
>> real issue with osg.
>> The issue seems to be related to the destruction of the default font, but 
>> i was not able to investigate further.
>> Attached is a Backtrace of the issue i am currently observing.
>>
>
> That stack trace looks like the automatic clean up of the ObjectCache with 
> the DefaultFont within it is related somehow to the crash.  How the 
> DefaultFont is managed has changed, to address bugs ironically, and in a 
> general sense the clean up the stack trace looks just fine to me, it's 
> roughly what I'd expect to happen.  However, I don't have any clear idea 
> why in this instance the crash has occurred.
>
> Given there isn't any obvious amiss we are unfortunately are left to widen 
> out the search for what is amiss. 
>
> Does running an OSG example like osgtext fail?
>
> Do others in the OpenMMW community seen this same crash?
>
> Is it possible to run OpenMMW single threaded to see if there might be 
> some thread interaction?
>
> What OS/compile and OpenMMW version combination are you using?
>
> One possible cause of crash like this is memory corruption during the run 
> of the application that is only revealed on clean up.  Using a memory tools 
> like valgrind might be spot this type of issue.
>
> Perhaps others might have seen something similar and can help shed some 
> light on the nature of the crash.
>
> If it's possible to recreate the crash with an standard OSG example, or a 
> small modification of one, then this would be really helpful for me to jump 
> in a start investigating the issue.
>
> Cheers.
> Robert.
>
>
>
>
>  
>
>
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/ff578130-867c-4c93-9fb0-fd573b20ab91%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

[OpenSceneGraph Users]

Hi Fiabian,

On Monday, 27 January 2020 09:41:43 UTC, Fabian Roth wrote:
>
> Hi,
> I am currently testing this RC with openmw.
> If i have the fps display or profiler open while exiting the application i 
> get a crash on exit.
> I am not sure if this is due to a bug in my build, a bug in openmw or a 
> real issue with osg.
> The issue seems to be related to the destruction of the default font, but 
> i was not able to investigate further.
> Attached is a Backtrace of the issue i am currently observing.
>

That stack trace looks like the automatic clean up of the ObjectCache with 
the DefaultFont within it is related somehow to the crash.  How the 
DefaultFont is managed has changed, to address bugs ironically, and in a 
general sense the clean up the stack trace looks just fine to me, it's 
roughly what I'd expect to happen.  However, I don't have any clear idea 
why in this instance the crash has occurred.

Given there isn't any obvious amiss we are unfortunately are left to widen 
out the search for what is amiss. 

Does running an OSG example like osgtext fail?

Do others in the OpenMMW community seen this same crash?

Is it possible to run OpenMMW single threaded to see if there might be some 
thread interaction?

What OS/compile and OpenMMW version combination are you using?

One possible cause of crash like this is memory corruption during the run 
of the application that is only revealed on clean up.  Using a memory tools 
like valgrind might be spot this type of issue.

Perhaps others might have seen something similar and can help shed some 
light on the nature of the crash.

If it's possible to recreate the crash with an standard OSG example, or a 
small modification of one, then this would be really helpful for me to jump 
in a start investigating the issue.

Cheers.
Robert.




 


 

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/d1bd2b26-bb79-4825-9082-f7d6713480f7%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

[OpenSceneGraph Users]

Hi,
I am currently testing this RC with openmw.
If i have the fps display or profiler open while exiting the application i 
get a crash on exit.
I am not sure if this is due to a bug in my build, a bug in openmw or a 
real issue with osg.
The issue seems to be related to the destruction of the default font, but i 
was not able to investigate further.
Attached is a Backtrace of the issue i am currently observing.

Greetings,
Fabian

*** Fatal Error ***
Invalid permissions for mapped object (signal 11)
Address: 0x5612597e50c0

* Backtrace

#2  0x7f13a65b7f20 in  () at 
/lib/x86_64-linux-gnu/libc.so.6
#3  0x5612597e50c0 in  ()
#4  0x56125898fdc4 in 
OpenThreads::ScopedPointerLock::ScopedPointerLock(OpenThreads::Mutex*)
 
() at ./openmw/extern-git/OpenSceneGraph/include/OpenThreads/ScopedLock:54
m = 0x5612597e5250
this = 
lock = {m_lock = 0x5612597e5250}
pitr = 
#5  0x56125898fdc4 in osg::StateAttribute::removeParent(osg::StateSet*) 
(this=0x5612647f58e0, object=, object@entry=0x5612647d48f0) 
at ./openmw/extern-git/OpenSceneGraph/src/osg/StateAttribute.cpp:38
lock = {m_lock = 0x5612597e5250}
pitr = 
#6  0x561258991d2c in osg::StateSet::clear() 
(this=this@entry=0x5612647d48f0) at 
./openmw/extern-git/OpenSceneGraph/src/osg/StateSet.cpp:734
itr = {_M_node = 0x5612647f5a80}
#7  0x561258991f96 in __base_dtor  (this=0x5612647d48f0) at 
./openmw/extern-git/OpenSceneGraph/src/osg/StateSet.cpp:285
#8  0x561258992129 in __deleting_dtor  (this=0x5612647d48f0) at 
./openmw/extern-git/OpenSceneGraph/src/osg/StateSet.cpp:286
#9  0x561258bad988 in signalObserversAndDelete (signalDelete=true, 
doDelete=true, this=0x5612647d48f0) at 
/usr/include/c++/7/bits/stl_construct.h:107
newRef = 
needDelete = 
#10 0x561258bad988 in osg::Referenced::unref() const 
(this=0x5612647d48f0) at 
./openmw/extern-git/OpenSceneGraph/include/osg/Referenced:201
newRef = 
needDelete = 
#11 0x561258bad988 in osg::ref_ptr::~ref_ptr() () at 
./openmw/extern-git/OpenSceneGraph/include/osg/ref_ptr:41
#12 0x561258bad988 in std::_Destroy 
>(osg::ref_ptr*) () at 
/usr/include/c++/7/bits/stl_construct.h:98
#13 0x561258bad988 in 
std::_Destroy_aux::__destroy*>(osg::ref_ptr*,
 
osg::ref_ptr*) () at 
/usr/include/c++/7/bits/stl_construct.h:108
#14 0x561258bad988 in 
std::_Destroy*>(osg::ref_ptr*, 
osg::ref_ptr*) () at 
/usr/include/c++/7/bits/stl_construct.h:137
#15 0x561258bad988 in std::_Destroy*, 
osg::ref_ptr >(osg::ref_ptr*, 
osg::ref_ptr*, std::allocator 
>&) () at /usr/include/c++/7/bits/stl_construct.h:206
#16 0x561258bad988 in std::vector, 
std::allocator > >::~vector() [clone 
.lto_priv.5148] (this=0x561264714620) at 
/usr/include/c++/7/bits/stl_vector.h:434
#17 0x561258bad988 in __base_dtor  (this=0x5612647145c0) at 
./openmw/extern-git/OpenSceneGraph/src/osgText/Font.cpp:295
#18 0x561258bada13 in __base_dtor  () at 
./openmw/extern-git/OpenSceneGraph/src/osgText/DefaultFont.cpp:35
this = 0x5612647145c0
#19 0x561258bada13 in __deleting_dtor  (this=0x5612647145c0) at 
./openmw/extern-git/OpenSceneGraph/src/osgText/DefaultFont.cpp:37
#20 0x561258a1b6b4 in signalObserversAndDelete (signalDelete=true, 
doDelete=true, this=0x5612647145c0) at 
./openmw/extern-git/OpenSceneGraph/src/osg/Referenced.cpp:281
newRef = 
needDelete = 
this = 0x561259805c38
__p = 0x56126472ce20
this = 0x561259805c38
__p = 0x56126472ce20
#21 0x561258a1b6b4 in osg::Referenced::unref() const 
(this=0x5612647145c0) at 
./openmw/extern-git/OpenSceneGraph/include/osg/Referenced:201
newRef = 
needDelete = 
this = 0x561259805c38
__p = 0x56126472ce20
this = 0x561259805c38
__p = 0x56126472ce20
#22 0x561258a1b6b4 in osg::ref_ptr::~ref_ptr() () at 
./openmw/extern-git/OpenSceneGraph/include/osg/ref_ptr:41
this = 0x561259805c38
__p = 0x56126472ce20
this = 0x561259805c38
__p = 0x56126472ce20
#23 0x561258a1b6b4 in std::pair, 
double>::~pair() () at /usr/include/c++/7/bits/stl_pair.h:208
this = 0x561259805c38
__p = 0x56126472ce20
this = 0x561259805c38
__p = 0x56126472ce20
#24 0x561258a1b6b4 in __base_dtor  (this=0x56126472ce40) at 
/usr/include/c++/7/bits/stl_pair.h:208
this = 0x561259805c38
__p = 0x56126472ce20
this = 0x561259805c38
__p = 0x56126472ce20
#25 0x561258a1b6b4 in 
__gnu_cxx::new_allocator, std::allocator >, osg::ref_ptr > const, std::pair, double> > > 
>::destroy, std::allocator >, osg::ref_ptr > const, std::pair, double> > 
>(std::pair, std::allocator >, osg::ref_ptr > const, std::pair, double> >*) () at 
/usr/include/c++/7/ext/new_allocator.h:140
this = 0x561259805c38
__p = 0x56126472ce20
this = 0x561259805c38
__p = 0x56126472ce20
#26 0x561258a1b6b4 in 

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

[OpenSceneGraph Users]

>
>
> It would be best to have 3.6.5 go out with support for recent VC and FBX 
> versions so would appreciate if you could generate a PR for them.  I can 
> merge them and make 3.6.5-rc3
>
> Cheers,
> Robert
>  
>

OK, done. https://github.com/openscenegraph/OpenSceneGraph/pull/907 

These changes fix my Windows VC builds but I'm no expert in CMake or the 
requirements of all the different builds so I suggest that this is reviewed 
by experienced OSG builders.

Cheers,
Stuart

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/2fcf7e29-5f6d-45e5-a85f-54546aa48c54%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

[Robert Osfield]

Hi Stuart,

On Sun, 26 Jan 2020 at 13:46, Stuart Mentzer  wrote:

> OSG 3.6.5-rc2 built fine on Windows with VC2019 (so VC2017 is probably OK)
> and appears to be running properly in our application. If there are more
> RCs I can try to test those and I should be able to get 3.6.5 binaries
> posted soon after it is released.
>

Great thanks.


> Other than the usual mods I make to build with VC using GNU make the FBX
> plugin support has some issues that I worked around, wrt CMake usage and
> support for the newer VC and FBX versions. I can share my fixed versions if
> you would like and you tell me the best way to do that now.
>

It would be best to have 3.6.5 go out with support for recent VC and FBX
versions so would appreciate if you could generate a PR for them.  I can
merge them and make 3.6.5-rc3

Cheers,
Robert
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

[Stuart Mentzer]

Hi Robert,

OSG 3.6.5-rc2 built fine on Windows with VC2019 (so VC2017 is probably OK) 
and appears to be running properly in our application. If there are more 
RCs I can try to test those and I should be able to get 3.6.5 binaries 
posted soon after it is released.

Other than the usual mods I make to build with VC using GNU make the FBX 
plugin support has some issues that I worked around, wrt CMake usage and 
support for the newer VC and FBX versions. I can share my fixed versions if 
you would like and you tell me the best way to do that now.

Cheers,
Stuart

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/19f2d491-8ffc-45fc-b7fe-5126c48ea797%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

[Andreas Ekstrand]

Hi,

Seems to work fine here!

Win10 Home
CMake 3.16.0-rc3
Visual Studio Express 2013

Regards,
Andreas


On 2020-01-24 20:26, Robert Osfield wrote:

HI All,

Still waiting on feedback on how well 3.6.5-rc2 is working OK.  I'm 
ready to tag 3.6.5 at my end as there are no Issue reported yet that I 
can look into resolving.


If there are no Issue's raised by Monday I'll go ahead and tag 3.6.5 
stable release.


Cheers,
Robert.
--
You received this message because you are subscribed to the Google 
Groups "OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to osg-users+unsubscr...@googlegroups.com 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/756a9af1-c0d5-4795-83fc-773a3d99130b%40googlegroups.com 
.


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

[Robert Osfield]

HI All,

Still waiting on feedback on how well 3.6.5-rc2 is working OK.  I'm ready 
to tag 3.6.5 at my end as there are no Issue reported yet that I can look 
into resolving.

If there are no Issue's raised by Monday I'll go ahead and tag 3.6.5 stable 
release.

Cheers,
Robert.

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/756a9af1-c0d5-4795-83fc-773a3d99130b%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org