[osg-users] CompositeViewer context cleanup and missing textures

Drolet, Frederic Frederic.Drolet at drdc-rddc.gc.ca
Tue Nov 24 07:50:24 PST 2009


Hi J-P,

I'm using OSG 2.8.2 but not the latest SVN build (the sources available on the website). I'm compiling the example with VS 2008. Maybe the crash is driver related... We're using a nVidia GeForce GTX 280.

In our application, the crash occurs sporadically (seems to be a threading issue) but in the OSG example, it occurs on every run at the same place.

I'll try it on Win XP... We've been having some strange threading behaviour differences between WinXP et WinVista these past few weeks (some induces performance issues and others cause the application to crash at different places when handling viewports). 

Some more fun in perspective! At least, I'll try the texture pool solution in the latest SVN build to see if it helps.

Thanks!

Frederic Drolet, M. Sc.
Computing Solutions and Experimentations | Solutions informatiques et expérimentations
Systems of Systems | Systèmes de systèmes
DRDC Valcartier | RDDC Valcartier
2459, boul. Pie-XI North
Quebec, Quebec
G3J 1X5 CANADA
Phone | Téléphone: (418) 844-4000 ext : 4820
Fax | Télécopieur: (418) 844-4538
E-mail | Courriel: frederic.drolet at drdc-rddc.gc.ca
Web : www.valcartier.drdc-rddc.gc.ca

-----Original Message-----
From: osg-users-bounces at lists.openscenegraph.org [mailto:osg-users-bounces at lists.openscenegraph.org] On Behalf Of J.P. Delport
Sent: November-24-09 10:17 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] CompositeViewer context cleanup and missing textures

Hi Frederic,

Drolet, Frederic wrote:
> Hello J.P.,
> 
> I see it's a good thing this thread got my attention! I have similar
> missing texture issues in another application that creates and
> deletes window contexts applied to viewer slaves (also created and
> deleted dynamically). Here's the way we create our textures:
> 
> osg::ref_ptr<osg::Texture2D> lTex = new osg::Texture2D; 
> lTex->setDataVariance(osg::Object::DYNAMIC);
> 
> // load an image by reading a file: CString lIconFileName =
> (...)TextureFilename + ".png"; osg::Image* lIconImage =
> osgDB::readImageFile(lIconFileName.GetBuffer());
> 
> // Assign the texture to the image we read from file: 
> lTex->setImage(lIconImage);
> 
> // Make sure the texture is not unreferenced in memory after it's
> applied in GL states lTex->setUnRefImageDataAfterApply(false);
> 
> Unfortunately, my understanding of OpenGL is relatively limited but I
> know this last line of code is crucial for dynamical views handling
> to maintain the texture in user memory for later access. However,
> even with this, it happens sometimes that the texture disappear after
> a few create and delete views operations (sometimes, the textures is
> on a view but not on another!). It happens most of the time with
> objects loaded from file. Since we don't have direct access to the
> textures, we can't make the call to setUnRefImageDataAfterApply().
> Would there be another way?

I'm not sure, but I think only the DB pager, optimiser and some plugins 
switch automatically to auto unref. Maybe try disabling the optimiser.

> 
> Now, as for the modified CompositeViewer example, I tried it on
> Windows Vista and it simply crashes the first time I hit ESC or the X
> button. In fact, the problem occurs during the second call to
> viewer.run(). First, I simply tried to add a sleep before the
> viewer's deletion to wait for potential asynchronous cleanup stuff
> after the call to the viewer's run() method but it didn't work.

What version of OSG?

> 
> Then, I did a little debug job to find out that the second time the
> viewer is created, the application crashes during the rendering
> traversal of the first call to frame() in the run thread loop. More
> precisely the application crashes in osgUtil::ScreneView::init() the
> first time the cull_draw operation is launched. Here's the call
> stack:
> 
> ntdll.dll!778f9a94() [Frames below may be incorrect and/or missing,
> no symbols loaded for ntdll.dll] ntdll.dll!778f92c4() 
> kernel32.dll!76a5e87b() nvoglv32.dll!69638b8f() 
> nvoglv32.dll!695a15d0()
>> osg55-osgd.dll!osg::getGLVersionNumber()  Line 48 + 0xd bytes	C++
> osg55-osgd.dll!osg::isGLExtensionOrVersionSupported(unsigned int
> contextID=0, const char * extension=0x5ac7a277, float
> requiredGLVersion=3.4028235e+038)  Line 82 + 0x5 bytes	C++ 
> osg55-osgd.dll!osg::isGLExtensionSupported(unsigned int contextID=0,
> const char * extension=0x5ac7a277)  Line 73 + 0x17 bytes	C++ 
> osg55-osgUtild.dll!osgUtil::SceneView::init()  Line 312 + 0x2d bytes
> C++ osg55-osgUtild.dll!osgUtil::SceneView::draw()  Line 1026 + 0x1d
> bytes	C++ osg55-osgViewerd.dll!osgViewer::Renderer::cull_draw()  Line
> 588 + 0xf bytes	C++ 
> osg55-osgViewerd.dll!osgViewer::Renderer::operator()(osg::GraphicsContext
> * context=0x023591b0)  Line 689 + 0xf bytes	C++ 
> osg55-osgd.dll!osg::GraphicsContext::runOperations()  Line 688 + 0x33
> bytes	C++ 
> osg55-osgViewerd.dll!osgViewer::ViewerBase::renderingTraversals()
> Line 772 + 0x15 bytes	C++ 
> osg55-osgViewerd.dll!osgViewer::ViewerBase::frame(double
> simulationTime=1.7976931348623157e+308)  Line 609 + 0xf bytes	C++ 
> osg55-osgViewerd.dll!osgViewer::ViewerBase::run()  Line 581 + 0x1b
> bytes	C++ osg55-osgViewerd.dll!osgViewer::CompositeViewer::run()
> Line 233	C++ osgcompositeviewerd.exe!main(int argc=3, char * *
> argv=0x02330ed8)  Line 311 + 0xf bytes	C++ 
> osgcompositeviewerd.exe!__tmainCRTStartup()  Line 582 + 0x19 bytes	C 
> osgcompositeviewerd.exe!mainCRTStartup()  Line 399	C 
> kernel32.dll!76a94911() ntdll.dll!778de4b6() ntdll.dll!778de489()
> 
> I forced the single thread mode (the only thing on the command line
> was the filename of my 3D model).
> 
> By the way, is there a better solution to wait for the viewer
> completion after the run() method?

When run completes I would hope it's done, I don't know of other ways.

> 
> What OS are you using? Maybe I should try on XP to see if it does the
> same thing.

J-S tried on Vista and it worked with latest OSG svn. I'm on Debian Sid 
32-bit.

jp

> 
> Hope we can help each other!
> 
> Cheers,
> 
> Frederic Drolet, M. Sc. Computing Solutions and Experimentations |
> Solutions informatiques et expérimentations Systems of Systems |
> Systèmes de systèmes DRDC Valcartier | RDDC Valcartier 2459, boul.
> Pie-XI North Quebec, Quebec G3J 1X5 CANADA Phone | Téléphone: (418)
> 844-4000 ext : 4820 Fax | Télécopieur: (418) 844-4538 E-mail |
> Courriel: frederic.drolet at drdc-rddc.gc.ca Web :
> www.valcartier.drdc-rddc.gc.ca
> 
> -----Original Message----- From:
> osg-users-bounces at lists.openscenegraph.org
> [mailto:osg-users-bounces at lists.openscenegraph.org] On Behalf Of J.P.
> Delport Sent: November-24-09 8:53 AM To: OpenSceneGraph Users 
> Subject: Re: [osg-users] CompositeViewer context cleanup and missing
> textures
> 
> Hi,
> 
> Robert Osfield wrote:
>> Hi J.P.
>> 
>> I'm still knee deep in merging submissions so can't yet go off 
>> reviewing user code.  In principle it is possible to mange open and
>>  closing viewers.  I can point you in the right direction but have
>> to let you get on with it otherwise.
> 
> I understand, I'll try search for cleanup code, just not sure where
> to start.
> 
> Anyone else?
> 
> jp
> 
>> Robert.
>> 
>> On Tue, Nov 24, 2009 at 12:32 PM, J.P. Delport
>> <jpdelport at csir.co.za> wrote:
>>> Hi Robert,
>>> 
>>> Robert Osfield wrote:
>>>> Hi J.P,
>>>> 
>>>> The typical problem is that the scene graph has been set up to
>>>> unref texture images after apply so when it comes to reloading
>>>> the texture images there aren't the to download.
>>> should this still happen when I'm completely reloading a scene
>>> after the viewer and scene have been deleted completely?
>>> 
>>> It seems that OSG thinks there is still a valid texture it can
>>> use after I've deleted the scene and CompositeViewer.
>>> 
>>> Running the attached e.g.: ./test cow.osg
>>> 
>>> Constructing PixelBufferObject for image=0x9547928 
>>> _maxTexturePoolSize=0 _maxBufferObjectPoolSize=0 Created new
>>> TextureObject, _numOfTextureObjects 1 Created new TextureObject,
>>> _numOfTextureObjects 1
>>> 
>>> now I click the X on the window and the app deletes the scene and
>>> viewer and creates them anew:
>>> 
>>> _maxTexturePoolSize=0 _maxBufferObjectPoolSize=0 Reusing
>>> orhpahned TextureObject, _numOfTextureObjects=1 Warning: detected
>>> OpenGL error 'invalid value' after RenderBin::draw(,) Reusing
>>> orhpahned TextureObject, _numOfTextureObjects=1 Warning: detected
>>> OpenGL error 'invalid value' after RenderBin::draw(,)
>>> 
>>> So it tries to reuse something that's not there? How can I
>>> convince OSG to drop all caches/buffers/GL objects?
>>> 
>>> jp
>>> 
>>> 
>>>> Robert.
>>>> 
>>>> On Tue, Nov 24, 2009 at 9:17 AM, J.P. Delport
>>>> <jpdelport at csir.co.za> wrote:
>>>>> Hi all,
>>>>> 
>>>>> I've run into the classic "missing textures" problem when
>>>>> stopping and restarting a compositeviewer multiple times in
>>>>> the same app. From previous threads on this problem it seems
>>>>> to be context cleanup/GL object cleanup that does not get
>>>>> done properly, but I'm just using the normal CompositeViewer
>>>>> and not messing with contexts/windows/sceneviews myself, so I
>>>>> thought the cleanup would be handled correctly.
>>>>> 
>>>>> Attached a very slightly modified compositeviewer example.
>>>>> All it does is create/destruct the compositeviewer 5 times.
>>>>> When the viewer is created for the second time, all my
>>>>> textures are gone (just run without any arguments).
>>>>> 
>>>>> Can anyone confirm the missing textures? Any hints as to what
>>>>> else needs to be done to make sure everything is
>>>>> cleared/flushed correctly?
>>>>> 
>>>>> thanks jp
>>>>> 
>>>>> -- This message is subject to the CSIR's copyright terms and
>>>>> conditions, e-mail legal notice, and implemented Open
>>>>> Document Format (ODF) standard. The full disclaimer details
>>>>> can be found at http://www.csir.co.za/disclaimer.html.
>>>>> 
>>>>> This message has been scanned for viruses and dangerous
>>>>> content by MailScanner, and is believed to be clean.
>>>>> MailScanner thanks Transtec Computers for their support.
>>>>> 
>>>>> 
>>>>> _______________________________________________ osg-users
>>>>> mailing list osg-users at lists.openscenegraph.org 
>>>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>>> 
>>>>> 
>>>>> 
>>>> _______________________________________________ osg-users
>>>> mailing list osg-users at lists.openscenegraph.org 
>>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>> 
>>>> 
>>> -- This message is subject to the CSIR's copyright terms and
>>> conditions, e-mail legal notice, and implemented Open Document
>>> Format (ODF) standard. The full disclaimer details can be found
>>> at http://www.csir.co.za/disclaimer.html.
>>> 
>>> This message has been scanned for viruses and dangerous content
>>> by MailScanner, and is believed to be clean.  MailScanner thanks
>>> Transtec Computers for their support.
>>> 
>>> 
>>> _______________________________________________ osg-users mailing
>>> list osg-users at lists.openscenegraph.org 
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>> 
>>> 
>>> 
>> _______________________________________________ osg-users mailing
>> list osg-users at lists.openscenegraph.org 
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>> 
> 

-- 
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.  MailScanner thanks Transtec Computers for their support.

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


More information about the osg-users mailing list