Re: [osg-users] Open Scene Graph 3.4.0 has bug when using two monitor setup

[Bruce Clay]

Hi,

I realize this is an old thread but I am having the same problem with OpensSceneGraph displaying on two monitors. It always crashes in Group::traverse called from NodeVisitor::traverse. If I turn off the second monitor it does not crash.

I have tested on osgViewer and other apps in the source tree. If I add the --SingleThreaded to the argments as described above it does not crash. I first encountered the problem with osgEarth but it seems to be in the osg threading somewhere. I am runningOSG version 3.4 on windows 7 using Visual Studio 2013

Thank you!

Cheers,
Bruce

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=69697#69697





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

[Robert Osfield]

HI Bruce,

There isn't we can say about what the problem might be from the few
details you have provided.

Could you post a full stack trace. Also does the problem occur for
all models? Does it occur with OSG examples like osgviewer?

Robert.

[Bruce Clay]

Robert:
For a basic test I ran osgViewer cessnafire.org. The results I get on my home machine are different from those of my work machine but it does crash on both systems. In both cases through it seems to be a threading issue. At home the stack traces looks like

> osg130-osgd.dll!osg::ref_ptr<osg::Operation>::ref_ptr<osg::Operation>(const osg::ref_ptr<osg::Operation> & rp) Line 32 C++
osg130-osgd.dll!osg::OperationQueue::getNextOperation(bool blockIfEmpty) Line 89 C++
osg130-osgd.dll!osg::OperationThread::run() Line 418 C++
osg130-osgd.dll!osg::GraphicsThread::run() Line 41 C++
ot20-OpenThreadsd.dll!OpenThreads::ThreadPrivateActions::StartThread(void * data) Line 113 C++
[External Code]
[Frames below may be incorrect and/or missing, no symbols loaded for msvcr120d.dll]

whereas at work it is always crash at the osg::Group traverse. I will send a stack trace from there tomorrow. At home I am running on Windows 7 Professional with an AMD Phenom II 6X 1090T and I have two Nvidia 550 graphics cards. The work system is an 8 core Dell laptop running Windows 7. but if I force it to single threaded it does not crash even will all of the monitors on.

I have also tried various other work systems some with Windows 7 and others windows 10 but I did not have a compiler that I could use for debugging on those systems so I don't know for sure where it crashed just that it did if I do not use SingleThreaded

Cheers,
Bruce

------------------
Read this topic online here:

http://forum.openscenegraph.org/viewtopic.php?p=69703#69703

[Robert Osfield]

Hi Bruce,

I am surprised that this is an issue, the OSG has long been able to
run multi-threaded across multiple monitors, it's a fundamental part
of the OSG design. I don't personally use Windows too often so there
might be a Windows specific issue that others under Windows didn't
pick up on the OSG-3.4 pre-release cycle. I would have expected
others to flag up the issue as well. Given this I don't have any
straight forward explanation to why it might be happening.

The stack trace doesn't really provide much insight to what is going
wrong unfortunately. Is it actually crashing in ref_optr<>?

Does it rendering any frames before crashing?

Did you build the OSG with defaults or adjust the settings for a
particular set of preferences?

Does multi-montior but single graphics card fail?

What has been your experience with other OSG version? I.e. did 3.2
fail in the same way as well? Have you tried git master?

Robert.

[Bruce Clay]

Robert:
The stack trace below is the one I promised to send from work. This system is a 8 core I7 Dell laptop running windows 7. I am using the standard setting from the 3.4 developer release. I have been working with osgEarth for a while and thought the crashes were coming from that but discovered the same thing when running osgViewer. I had several issues getting Cmake to create valid solutions with osg 3.3.7 so I moved to the latest version to avoid wasting time on an old release. I have been away from OSG for a while so I can not say when the issue first came up. The errors in the list are different from what I was seeing before but I did do a full rebuild to see if that fixed anything. No matter where the crash is it always seems to be in an area of code related to threads. Yes I do see graphic frames updated before the crash sometime it stays up longer than others before crashing. I never have the crash though if I force single threading. I think the code tree I am
using if from 17 Nov. 2016. As I recall we did not have any problems with version 3.2 but I do not have that version to go back and run the test.

Thank you!

Cheers,
Bruce

Run 1 - osgViewer cessnafire.osg
> osg130-osgViewerd.dll!osgViewer::ViewerBase::renderingTraversals() Line 822 C++
osg130-osgViewerd.dll!osgViewer::ViewerBase::frame(double simulationTime) Line 687 C++
osg130-osgViewerd.dll!osgViewer::ViewerBase::run() Line 654 C++
osg130-osgViewerd.dll!osgViewer::Viewer::run() Line 421 C++
osgviewerd.exe!main(int argc, char * * argv) Line 181 C++
[External Code]
[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]

Run 2 - osgViewer cessnafire.osg

> osg130-osgd.dll!osg::ref_ptr<osg::Operation>::ref_ptr<osg::Operation>(const osg::ref_ptr<osg::Operation> & rp) Line 32 C++
osg130-osgd.dll!osg::OperationQueue::getNextOperation(bool blockIfEmpty) Line 89 C++
osg130-osgd.dll!osg::OperationThread::run() Line 418 C++

ot20-OpenThreadsd.dll!OpenThreads::ThreadPrivateActions::StartThread(void * data) Line 113 C++
[External Code]
[Frames below may be incorrect and/or missing, no symbols loaded for msvcr120d.dll]

Run 3 - osgViewer cessnafire.osg

04edb708() Unknown
[Frames below may be incorrect and/or missing]

> ot20-OpenThreadsd.dll!OpenThreads::ThreadPrivateActions::StartThread(void * data) Line 113 C++
[External Code]

Run 4 - osgViewer cessnafire.osg

> osg130-osgd.dll!osg::ref_ptr<osg::Operation>::ref_ptr<osg::Operation>(const osg::ref_ptr<osg::Operation> & rp) Line 32 C++
osg130-osgd.dll!osg::OperationQueue::getNextOperation(bool blockIfEmpty) Line 89 C++
osg130-osgd.dll!osg::OperationThread::run() Line 418 C++

ot20-OpenThreadsd.dll!OpenThreads::ThreadPrivateActions::StartThread(void * data) Line 113 C++
[External Code]
[Frames below may be incorrect and/or missing, no symbols loaded for msvcr120d.dll]

Rebuilt OSG

Run 5 - osgViewer cessnafire.osg

> osg130-osgd.dll!osg::ref_ptr<osg::Operation>::ref_ptr<osg::Operation>(const osg::ref_ptr<osg::Operation> & rp) Line 32 C++
osg130-osgd.dll!osg::OperationQueue::getNextOperation(bool blockIfEmpty) Line 89 C++
osg130-osgd.dll!osg::OperationThread::run() Line 418 C++

ot20-OpenThreadsd.dll!OpenThreads::ThreadPrivateActions::StartThread(void * data) Line 113 C++
[External Code]
[Frames below may be incorrect and/or missing, no symbols loaded for msvcr120d.dll]

Run 6 - osgViewer cessnafire.osg
> osg130-osgUtild.dll!osgUtil::PositionalStateContainer::draw(osg::State & state, osgUtil::RenderLeaf * & previous, const osg::Matrixd * postMultMatrix) Line 64 C++
osg130-osgUtild.dll!osgUtil::RenderStage::drawImplementation(osg::RenderInfo & renderInfo, osgUtil::RenderLeaf * & previous) Line 1404 C++
osg130-osgUtild.dll!osgUtil::RenderBin::draw(osg::RenderInfo & renderInfo, osgUtil::RenderLeaf * & previous) Line 430 C++
osg130-osgUtild.dll!osgUtil::RenderStage::drawInner(osg::RenderInfo & renderInfo, osgUtil::RenderLeaf * & previous, bool & doCopyTexture) Line 940 C++
osg130-osgUtild.dll!osgUtil::RenderStage::draw(osg::RenderInfo & renderInfo, osgUtil::RenderLeaf * & previous) Line 1249 C++
osg130-osgUtild.dll!osgUtil::SceneView::draw() Line 1366 C++
osg130-osgViewerd.dll!osgViewer::Renderer::draw() Line 751 C++
osg130-osgViewerd.dll!osgViewer::Renderer::operator()(osg::GraphicsContext * __formal) Line 911 C++
osg130-osgd.dll!osg::GraphicsContext::runOperations() Line 771 C++
osg130-osgd.dll!osg::RunOperations::operator()(osg::GraphicsContext * context) Line 139 C++
osg130-osgd.dll!osg::GraphicsOperation::operator()(osg::Object * object) Line 53 C++
osg130-osgd.dll!osg::OperationThread::run() Line 432 C++

osg130-osgd.dll!osg::GraphicsThread::run() Line 41 C++
ot20-OpenThreadsd.dll!OpenThreads::ThreadPrivateActions::StartThread(void * data) Line 113 C++
[External Code]
[Frames below may be incorrect and/or missing, no symbols loaded for msvcr120d.dll]

Run 7 - osgViewer cessnafire.osg

> osg130-osgd.dll!osg::ref_ptr<osg::Operation>::ref_ptr<osg::Operation>(const osg::ref_ptr<osg::Operation> & rp) Line 32 C++
osg130-osgd.dll!osg::OperationQueue::getNextOperation(bool blockIfEmpty) Line 89 C++
osg130-osgd.dll!osg::OperationThread::run() Line 418 C++

ot20-OpenThreadsd.dll!OpenThreads::ThreadPrivateActions::StartThread(void * data) Line 113 C++
[External Code]
[Frames below may be incorrect and/or missing, no symbols loaded for msvcr120d.dll]

Run 8 - osgViewer cessnafire.osg

> osg130-osgd.dll!osg::ref_ptr<osg::Operation>::ref_ptr<osg::Operation>(const osg::ref_ptr<osg::Operation> & rp) Line 32 C++
osg130-osgd.dll!osg::OperationQueue::getNextOperation(bool blockIfEmpty) Line 89 C++
osg130-osgd.dll!osg::OperationThread::run() Line 418 C++

ot20-OpenThreadsd.dll!OpenThreads::ThreadPrivateActions::StartThread(void * data) Line 113 C++
[External Code]
[Frames below may be incorrect and/or missing, no symbols loaded for msvcr120d.dll]

------------------
Read this topic online here:

http://forum.openscenegraph.org/viewtopic.php?p=69709#69709

[Robert Osfield]

Hi

> The stack trace below is the one I promised to send from work. This system is a 8 core I7 Dell laptop running windows 7. I am using the standard setting from the 3.4 developer release. I have been working with osgEarth for a while and thought the crashes were coming from that but discovered the same thing when running osgViewer. I had several issues getting Cmake to create valid solutions with osg 3.3.7 so I moved to the latest version to avoid wasting time on an old release. I have been away from OSG for a while so I can not say when the issue first came up. The errors in the list are different from what I was seeing before but I did do a full rebuild to see if that fixed anything. No matter where the crash is it always seems to be in an area of code related to threads. Yes I do see graphic frames updated before the crash sometime it stays up longer than others before crashing. I never have the crash though if I force single threading. I think the code tree I
am
> using if from 17 Nov. 2016. As I recall we did not have any problems with version 3.2 but I do not have that version to go back and run the test.

Thanks for the strack trace. Alas still no good lead on what might be
the cause of the problem.

When your say 3.4 developer release it muddies the water a bit as it
mixes terminology and versions so I'm clear which version you are
working with. For even point release like 3.4.x are all stable
releases, while uneven point versions like 3.5.x are all developer
releases.

Would it be possible for you test test OSG git master?

Robert.

[Bruce Clay]

Robert:
Just to be sure I pulled the latest git release and diffed it against the code I had and only found differences in commented headers. I built the code as I had previously and got the same errors. I am using the 32 bit version of 3rd party dependencies which is not the latest posted but only a 64 bit version of the latest dependencies is posted and I need a 32 bit app.

I tried a couple of different things based on flags I saw in the cmake file.

first I tried using the OSG_MULTIMONITOR_WIN32_NVIDIA_WORKAROUND flag. I rebuilt the entire package and ran osgViewer cessnafire.osg. In this configuration, the program sometime crashed immediately with no scene display and other times ran fine. It we still to unstable to leave in this configuration.

next I turned off the flag set in the previous step and tried the BUILD_OPENTHREADS_WITH_QT flag and rebuilt the package. With this configuration, osgViewer never crashed but some of the other / larger apps still crashed. I can not name those that crashed or where they crashed at this moment because I am installing Visual Studio 2015 and the installer won't let me run any version of Visual Studio while it is doing a setup. It did still point towards a threading problem though. I can check tomorrow when the install is finished. Hope this sheds some light on the problem. I will try vs2015 tomorrow as well.

Bruce

------------------
Read this topic online here:

http://forum.openscenegraph.org/viewtopic.php?p=69712#69712

[webmaster]

Hi Bruce Clay

  According my experience,you can try to upgrade your display driver to the newest version,mostly the problem will disappear.

 zhuwan

 12,20,2016

> -----原始邮件-----
> 发件人: "Bruce Clay" <bcla...@gmail.com>
> 发送时间: 2016-12-20 5:34:08
> 收件人: osg-...@lists.openscenegraph.org
> 抄送: 
> 主题: Re: [osg-users] Open Scene Graph 3.4.0 has bug when using two monitor setup
> 
> Robert:
>   Just to be sure I pulled the latest git release and diffed it against the code I had and only found differences in commented headers.  I built the code as I had previously and got the same errors.  I am using the 32 bit version of 3rd party dependencies which is not the latest posted but only a 64 bit version of the latest dependencies is posted and I need a 32 bit app.
> 
> I tried a couple of different things based on flags I saw in the cmake file.
> 
> first I tried using the OSG_MULTIMONITOR_WIN32_NVIDIA_WORKAROUND flag.  I rebuilt the entire package and ran osgViewer cessnafire.osg.  In this configuration, the program sometime crashed immediately with no scene display and other times ran fine.  It we still to unstable to leave in this configuration.
> 
> next I turned off the flag set in the previous step  and tried the BUILD_OPENTHREADS_WITH_QT flag and rebuilt the package.  With this configuration, osgViewer never crashed but some of the other / larger apps still crashed.   I can not name those that crashed or where they crashed at this moment because I am installing Visual Studio 2015 and the installer won't let me run any version of Visual Studio while it is doing a setup.  It did still point towards a threading problem though.  I can check tomorrow when the install is finished.  Hope this sheds some light on the problem.  I will try vs2015 tomorrow as well.
> 
> Bruce
> 
> ------------------
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=69712#69712

[Robert Osfield]

Hi Bruce,

On 19 December 2016 at 21:34, Bruce Clay <bcla...@gmail.com> wrote:
> Robert:
> Just to be sure I pulled the latest git release and diffed it against the code I had and only found differences in commented headers. I built the code as I had previously and got the same errors. I am using the 32 bit version of 3rd party dependencies which is not the latest posted but only a 64 bit version of the latest dependencies is posted and I need a 32 bit app.
>
> I tried a couple of different things based on flags I saw in the cmake file.
>
> first I tried using the OSG_MULTIMONITOR_WIN32_NVIDIA_WORKAROUND flag. I rebuilt the entire package and ran osgViewer cessnafire.osg. In this configuration, the program sometime crashed immediately with no scene display and other times ran fine. It we still to unstable to leave in this configuration.

I've just looked at the history of GraphicsWindowWin32.cpp, the
OSG_MULTIMONITOR_WIN32_NVIDIA_WORKAROUND is a workaround for an NVidia
driver bug from 8 years ago, I'd hope that it's no longer relevant...

https://github.com/openscenegraph/OpenSceneGraph/commit/7c23951ee17ab444220220951dae16df7c691e2a

> next I turned off the flag set in the previous step and tried the BUILD_OPENTHREADS_WITH_QT flag and rebuilt the package. With this configuration, osgViewer never crashed but some of the other / larger apps still crashed. I can not name those that crashed or where they crashed at this moment because I am installing Visual Studio 2015 and the installer won't let me run any version of Visual Studio while it is doing a setup. It did still point towards a threading problem though. I can check tomorrow when the install is finished. Hope this sheds some light on the problem. I will try vs2015 tomorrow as well.

The effect of shifting the BUILD_OPENTHREADS_WITH_QT suggests a either
that the bug is timing sensitive or the OpenThreads::Win32 implement
is not protecting threads as it should be. It may be worth looking at
the differences between OSG-3.2 and 3.4 w.r.t OpenThreads, perhaps one
of the "fixes" has actually caused a regression.

Do you have any non NVidia or non Windows setups?

Robert

[Wojciech Lewandowski]

Hi Bruce,

Just from top of my head. 

1. Check and verify if all osgXXX.dll and OpenThreads.dll are loaded from correct installation directories. Similar errors often occur if Debug/Release/Rev libs get mixed. VS Output pane displays all loaded DLLs with long paths so its easy to verify if some lib was not picked from other path.

2. Check if Call stack does not show some crashes in Nvidia OpenGL threads. Sometimes errors there affect the other threads which invoked OpenGL calls. Also check NVidia Control Panel. There is Multithreaded Optimization setting (actual names may vary a little as I am using my localized language version and cannot check them in English). Experiment with it. Perhaps one of the options will fix the problem.

3. I checked the version of OSG I have installed on my machine currently (OSG 3.4.0). osgViewer does not crash with cessna in dual screen (Window10/GTX 1080 drivers 375.95). But it is 64 bit build. So your 32 bit results may still vary.

Cheers,

Wojtek Lewandowski

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