Hang in ViewerBase::stopThreading

44 views
Skip to first unread message

Ben Meijering

unread,
Dec 28, 2021, 9:18:09 AM12/28/21
to osg-...@googlegroups.com
Hi everyone,

I am looking into a hang that occurred on the system of one of my colleagues and I was hoping anyone might be able to help me out.
Unfortunately I haven't been able to reproduce it on my own system, but looking at the forced "crash" dump, I see the following:

* we are using the DrawThreadPerContext threading model
* the software hangs in ViewerBase::stopThreading in a setGraphicsThread(0) call
* it hangs there because a graphics thread hangs at osgViewer::Renderer::draw at _drawQueue.takeFront()
* Renderer::_drawQueue._isReleased is false, while Renderer::_availableQueue._isReleased is true and Renderer::_done is true (so Renderer::release has been called in ViewerBase::stopThreading)

The only thing I could find in the code that might produce this last situation is that Renderer::ThreadSafeQueue::takeFront sets  Renderer::ThreadSafeQueue::  _isReleased to false again in certain situations.
In ViewerBase::stopThreading, I see that first all cameras are released, however, if the graphics thread is able to run it's operations multiple times before stopThreading attempts to kill the thread (setGraphicsThread(0)), it might be that
Renderer::draw is executed again, causing the hang.

Could it be that this is caused by Renderer::ThreadSafeQueue::takeFront setting _isReleased to false and is it really necessary to set _isReleased to false there ?
If so, could a check for _done at the beginning of Renderer::draw perhaps be a better option ?

I just want to be sure, as changes here might be dangerous, so I am hoping that anyone who is familiar with the code could help me out.

Thanks in advance.

Cheers,

Ben

Robert Osfield

unread,
Dec 29, 2021, 5:51:31 AM12/29/21
to OpenSceneGraph Users
Hi Ben,

I'm away on a family trip and it's been a while since I've worked on the viewer threading code, so I'm not in a good place to provide good answers or support at this point. 

With your suggestion of checking for _done in Renderer::draw(), it would be worth just trying it and seeing if things are more stable. This would provide another data point to what might be going on and what might be a reasonable fix.

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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osg-users/CAAb_kVaYEGwY52VEtoFR9npv_Qs6DSyoqf%3DvzeQLWJt0%2BjyV%2Bw%40mail.gmail.com.

Ben Meijering

unread,
Dec 29, 2021, 6:25:12 AM12/29/21
to osg-...@googlegroups.com
Hi Robert,

Thanks for your response.

Yesterday I added the check for _done at the beginning of Renderer::draw.
My colleague who was previously able to reproduce the issue on his system quite often (1 out of 8 tries), has not been able to reproduce it anymore (and he tried it a lot more than 8 times).
He will continue using this build, so we'll see how it holds up.

However, because I don't have in-depth knowledge of this code and because it's easy to overlook unintended consequences in situations like these, I just wanted to be sure and would love to hear it if anyone thinks this might not be the correct solution.

Cheers,

Ben


Op wo 29 dec. 2021 om 11:51 schreef Robert Osfield <robert....@gmail.com>:

Ben Meijering

unread,
Feb 25, 2022, 5:12:26 AM2/25/22
to osg-...@googlegroups.com
Hi everyone,

I just wanted to add another data point.
We have been using the check for _done at the beginning of Renderer::draw for quite a while now and we haven't experienced any hangs anymore, or issues related to this change.

Cheers,

Ben

Op wo 29 dec. 2021 om 12:24 schreef Ben Meijering <bjs.me...@gmail.com>:
Reply all
Reply to author
Forward
0 new messages