[osg-users] New OpenGL texture object and buffer object pool support

[Robert Osfield]

Hi All,

I've been pretty quiet and the public list/forum through September,
keeping my head down developing new functionality for the OSG... and
the new functionality I'm pleased to announce today is that we now
have a loverly new back-end implementation for texture objects and
buffer objects (VertexBufferObject, ElementBufferObjects and
PixelBufferObjects's) that provides a set of GL objects pools that
enable recycling of both orphaned GL objects and reuse of GL objects
that are still attached to the scene graph, but are stale - i.e.
haven't been rendered in the last frame.

The benefit the GL object pools provide is that we can scale up the
scene graph in main memory without blowing OpenGL driver and GPU
memory as we would do without the new pools. This feature also
reduces the likely-hood of thrashing of OpenGL driver and GPU memory
so that where we might have previously seen frame drops due to memory
management we avoid them completely or reduce there impact. The
memory pools will come in there own once we scale down the GPU memory
size, such as embedded systems, or on desktop/workstation applications
where GPU memory can be overflowed due to massive databases being kept
in main memory. In the later case this issue is more compounded on
some OS's, such as Vista, that limits the amount of memory that OpenGL
drivers can allocate, so here it should help make the app more stable
(avoid the crashes due to out of memory errors) and faster.

So... how to try out the new texture and buffer object pools? First
up you'll need to update to the latest OpenScenGraph svn/trunk. Next
you'll need to enable the pools by setting the env vars: (example
below for bash)

export OSG_TEXTURE_POOL_SIZE=100000000 // size in bytes (100Mb)
export OSG_BUFFER_OBJECT_POOL_SIZE=200000000 // size in bytes (200Mb)

Then run your app with some big data, such a large paged database, you
can push the amount of main memory used by enabling the MaxPagedLOD
feature in the DatabasePager via:

export OSG_MAX_PAGEDLOD=100000 // keep in memory a maximum of
100,000 PagedLOD nodes

You can also set these values programmatically via osg::DisplaySettings.

A word of warning though, I have almost completely rewritten the way
that the backend that drives texture objects and buffer objects, even
when you don't enable the texture/buffer object pools, the code
managing the GL objects is still completely different. With major
changes like this comes the likelihood of regressions. I've been
doing a range of tests at my end, but it's still far more limited in
scope to what the community will expose the OSG to, so... there you
may way see problems that I haven't. The best I can do is endeavor to
get them fixed as quickly as possible, just let me know if you see
something odd and I we can work together to spot what the underlying
problem and squish it. The more testing we can get the quicker we can
shape the code up to being release quality.

Have fun with it :-)
Robert.
_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[Robert Osfield]

> So... how to try out the new texture and buffer object pools?   First
> up you'll need to update to the latest OpenScenGraph svn/trunk.

You'll need to wait, my attempt to check changes in has failed due to
problems connecting to the server.. I'll ping the list once things
are successfully checked in.

Cheers,

[Robert Osfield]

Hi All,

On Fri, Oct 2, 2009 at 10:24 PM, Robert Osfield
<robert....@gmail.com> wrote:
> You'll need to wait, my attempt to check changes in has failed due to
> problems connecting to the server..  I'll ping the list once things
> are successfully checked in.

Changes now checked in. For majority of users no code changes in your
application should be required as it's principally the backend that's
changed radically, but for a small number of users that dig down to
lower level management of buffer objects/texture objects you may need
to adapt your code.

Fingers crossed that it won't break the build, or runtime.... Please
test throughly and let me know how you get on.

[Wang Rui]

Hi Robert,

 

Some errors on my WindowsXP SP2 + VS2008 while building SceneView.cpp.

 

Modify the code at line 1028:

 

osg::GLBufferObjectManager::GLBufferObjectManager* bom = osg::GLBufferObjectManager::getGLBufferObjectManager(state->getContextID());

 

to:

 

osg::GLBufferObjectManager* bom = osg::GLBufferObjectManager::getGLBufferObjectManager(state->getContextID());

 

And it builds well.

 

I will help test the exciting new texture pool functionality with my 80GB Tibet buildings data after the Chinese National Day holidays. :)

Wang Rui

2009/10/3 Robert Osfield <robert....@gmail.com>

[Paul Martz]

Hi Robert -- Current svn builds OK on OSX, but osgDB::ReadNodeFile is
coming up as an undefined symbol when I try to build any of my own code.
Note that the OSG examples all appear to build fine. So this is an odd one.

Windows build is underway.

I'll look into this further and let you know if I find anything.

Paul Martz
Skew Matrix Software LLC
_http://www.skew-matrix.com_ <http://www.skew-matrix.com/>
+1 303 859 9466

[Robert Osfield]

Thanks Wang Rui, I've made your suggestion change and checked in into
svn/trunk. Cheers, Robert.

[Robert Osfield]

Hi Paul,

On Sat, Oct 3, 2009 at 3:17 PM, Paul Martz <pma...@skew-matrix.com> wrote:
> Hi Robert -- Current svn builds OK on OSX, but osgDB::ReadNodeFile is coming
> up as an undefined symbol when I try to build any of my own code. Note that
> the OSG examples all appear to build fine. So this is an odd one.

I haven't made any changes to osgDB::readNodeFile, is there a chance
that a build error elsewhere has caused osgDB to not build and link
properly?

> Windows build is underway.

You'll need the change suggested by Wang Rui, this is now checked into
svn/trunk so an update should get you on your way.

> I'll look into this further and let you know if I find anything.

Thanks,
Robert.

[Tony Horrobin]

Hi Robert,

On Vista SP2 with Visual C++ 2005:

osgparametric fails with unresolved symbol osg::BufferData::setBufferObject(class osg::BufferObject *)

I believe this is due to missing OSG_EXPORT for BufferData in osg/BufferObject.
BufferObjectProfile is also missing OSG_EXPORT but this doesn't appear to cause problems at the moment.

Recompiling now.

Cheers,
Tony

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

[Paul Martz]

Robert Osfield wrote:
> On Sat, Oct 3, 2009 at 3:17 PM, Paul Martz <pma...@skew-matrix.com> wrote:
>> Hi Robert -- Current svn builds OK on OSX, but osgDB::ReadNodeFile is coming
>> up as an undefined symbol when I try to build any of my own code. Note that
>> the OSG examples all appear to build fine. So this is an odd one.
>
> I haven't made any changes to osgDB::readNodeFile, is there a chance
> that a build error elsewhere has caused osgDB to not build and link
> properly?

Yeah, I suspected I had some kind of build inconsistency too, it just
didn't smell like it was related to your changes. Indeed this was the
case. After cleaning out several accumulated installs and rebuilding,
everything is fine with current svn on OSX, as near as I can tell. Thanks.
-Paul

[Paul Martz]

Tony Horrobin wrote:
> Hi Robert,
>
> On Vista SP2 with Visual C++ 2005:
>
> osgparametric fails with unresolved symbol
osg::BufferData::setBufferObject(class osg::BufferObject *)

I saw this on OSX as well, buried in amongst all the readNodeFile calls
that came up undefined. This was a bad build and install on my system.
Cleaning things out and rebuilding resolved both issues.

Paul Martz
Skew Matrix Software LLC
_http://www.skew-matrix.com_ <http://www.skew-matrix.com/>
+1 303 859 9466

_______________________________________________

[Robert Osfield]

Thanks for the testing and pinpointing of the error. I've added an
OSG_EXPORT to BufferData and checked this in. BufferObjectProfile
won't need an export at it's a class entirely defined in the header.
Cheers, Robert.

[J.P. Delport]

Hi Robert,

Robert Osfield wrote:
> A word of warning though, I have almost completely rewritten the way
> that the backend that drives texture objects and buffer objects, even
> when you don't enable the texture/buffer object pools, the code
> managing the GL objects is still completely different. With major
> changes like this comes the likelihood of regressions. I've been
> doing a range of tests at my end, but it's still far more limited in
> scope to what the community will expose the OSG to, so... there you
> may way see problems that I haven't. The best I can do is endeavor to
> get them fixed as quickly as possible, just let me know if you see
> something odd and I we can work together to spot what the underlying
> problem and squish it. The more testing we can get the quicker we can
> shape the code up to being release quality.

I have problems with PBOs since updating to the latest svn. I'm not
setting any pool env variables. One can recreate the problem with
osgmovie. E.g.

$ osgmovie --mouse --interactive --shaders -e ffmpeg file.avi

_maxTexturePoolSize=0
_maxBufferObjectPoolSize=0
GLBufferObjectSet::GLBufferObjectSet _profile._size=1228800
Error numInList + _orphanedTextureObjects.size() != _numOfTextureObjects
numInList = 1
_orphanedTextureObjects.size() = 0
_pendingOrphanedTextureObjects.size() = 0
_numOfTextureObjects = 0
terminate called after throwing an instance of 'char const*'
Aborted

Can you confirm if this happens on your side too?

jp

>
> Have fun with it :-)
> Robert.
> _______________________________________________
> osg-users mailing list
> osg-...@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.

[pankaj nagarkoti]

The benefit the GL object pools provide is that we can scale up the
scene graph in main memory without blowing OpenGL driver and GPU
memory as we would do without the new pools.

------------------

Read this topic online here:

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

[Robert Osfield]

HI J.P.,

On Tue, Oct 6, 2009 at 8:26 AM, J.P. Delport <jpde...@csir.co.za> wrote:
> I have problems with PBOs since updating to the latest svn. I'm not setting
> any pool env variables. One can recreate the problem with osgmovie. E.g.
>
> $ osgmovie --mouse --interactive --shaders -e ffmpeg file.avi
>
> _maxTexturePoolSize=0
> _maxBufferObjectPoolSize=0
> GLBufferObjectSet::GLBufferObjectSet _profile._size=1228800
> Error numInList + _orphanedTextureObjects.size() != _numOfTextureObjects
>    numInList = 1
>    _orphanedTextureObjects.size() = 0
>    _pendingOrphanedTextureObjects.size() = 0
>    _numOfTextureObjects = 0
> terminate called after throwing an instance of 'char const*'
> Aborted
>
> Can you confirm if this happens on your side too?

Just tested this and I can confirm it happens for me too. I did have
this working as it was one of the elements I first tested, but alas
there has clearly been a regression as I completed the rest of the
task.

I will investigate what had gone a miss.

[Robert Osfield]

Hi J.P.

On Tue, Oct 6, 2009 at 9:01 AM, Robert Osfield <robert....@gmail.com> wrote:
> Just tested this and I can confirm it happens for me too.  I did have
> this working as it was one of the elements I first tested, but alas
> there has clearly been a regression as I completed the rest of the
> task.
>
> I will investigate what had gone a miss.

I have now tracked down the problem to a bug in the reassignment of
TextureObject to a new TextureObjectSet, this is now fixed along with
a couple of other bugs due to the unrefAfterApply not being disabled
when the texture pool is enabled. These fixes are now checked into
svn/trunk.

I am currently seeing GL errors reported when running osgmovie of the form:

Warning: detected OpenGL error 'invalid enumerant' after applying
attribute TextureRectangle 0x1fdb4e0

With the onscreen image being corrupted, while if I select a Texture2D
using the osgmovie command line option --texture2D I get:

Warning: detected OpenGL error 'invalid enumerant' after applying
attribute Texture2D 0x1c724e0

But the onscreen image is correct. If comment out the assignment of
the PixelBufferObject in the ImageStream constructor the on screen
errors and the console warnings all disappear so it looks to be a PBO
issue of some kind. I've only tried out this on my ATI card so far so
it could be driver issue.

What results do you get with the bug fixes I've just checked in?

[J.P. Delport]

Hi Robert,

Robert Osfield wrote:
>>
>> I will investigate what had gone a miss.
>
> I have now tracked down the problem to a bug in the reassignment of
> TextureObject to a new TextureObjectSet, this is now fixed along with
> a couple of other bugs due to the unrefAfterApply not being disabled
> when the texture pool is enabled. These fixes are now checked into
> svn/trunk.
>
> I am currently seeing GL errors reported when running osgmovie of the form:
>
> Warning: detected OpenGL error 'invalid enumerant' after applying
> attribute TextureRectangle 0x1fdb4e0
>
> With the onscreen image being corrupted, while if I select a Texture2D
> using the osgmovie command line option --texture2D I get:
>
> Warning: detected OpenGL error 'invalid enumerant' after applying
> attribute Texture2D 0x1c724e0
>
> But the onscreen image is correct. If comment out the assignment of
> the PixelBufferObject in the ImageStream constructor the on screen
> errors and the console warnings all disappear so it looks to be a PBO
> issue of some kind. I've only tried out this on my ATI card so far so
> it could be driver issue.
>
> What results do you get with the bug fixes I've just checked in?

I've just updated and now I get a single corrupted image flashed onto
the screen and then a segfault.

$ osgmovie --mouse --interactive --shaders -e ffmpeg file.avi

image->s()640 image-t()=480 aspectRatio=1
_maxTexturePoolSize=0
_maxBufferObjectPoolSize=0
Created new TextureObject, _numOfTextureObjects 1
GLBufferObjectSet::GLBufferObjectSet _profile._size=1228800
Segmentation fault

If I run in gdb the corrupted image stays, but I'll have to recompile
with debug info to give you a more sensible backtrace. Tomorrow... have
to go now.

jp

---8<---
Created new TextureObject, _numOfTextureObjects 1
GLBufferObjectSet::GLBufferObjectSet _profile._size=1228800

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb2952b90 (LWP 22742)]
0xb6d69e60 in ?? () from /usr/lib/libGLcore.so.1
(gdb) bt
#0 0xb6d69e60 in ?? () from /usr/lib/libGLcore.so.1
Cannot access memory at address 0xa04
(gdb) thread
[Current thread is 5 (Thread 0xb2952b90 (LWP 22742))]
(gdb) info threads
* 5 Thread 0xb2952b90 (LWP 22742) 0xb6d69e60 in ?? ()
from /usr/lib/libGLcore.so.1
4 Thread 0xb3c81b90 (LWP 22741) 0xb7fe1424 in __kernel_vsyscall ()
3 Thread 0xb4482b90 (LWP 22740) 0xb7fe1424 in __kernel_vsyscall ()
2 Thread 0xb4c83b90 (LWP 22739) 0xb7fe1424 in __kernel_vsyscall ()
1 Thread 0xb62a8950 (LWP 22736) 0xb7fe1424 in __kernel_vsyscall ()

>
> Robert.
> _______________________________________________
> osg-users mailing list
> osg-...@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.

_______________________________________________

[J.P. Delport]

Hi Robert,

>> What results do you get with the bug fixes I've just checked in?
>
> I've just updated and now I get a single corrupted image flashed onto
> the screen and then a segfault.
>
> $ osgmovie --mouse --interactive --shaders -e ffmpeg file.avi
> image->s()640 image-t()=480 aspectRatio=1
> _maxTexturePoolSize=0
> _maxBufferObjectPoolSize=0
> Created new TextureObject, _numOfTextureObjects 1
> GLBufferObjectSet::GLBufferObjectSet _profile._size=1228800
> Segmentation fault
>
> If I run in gdb the corrupted image stays, but I'll have to recompile
> with debug info to give you a more sensible backtrace. Tomorrow... have
> to go now.

Debug build still did not provide a nice backtrace, but I've followed
the crash to

void TextureRectangle::applyTexImage_subload in TextureRectangle.cpp

At the line:

dataPtr = reinterpret_cast<unsigned
char*>(pbo->getOffset(image->getBufferIndex()));

dataPtr gets assigned 0 and then the glTexSubImage2D call generates the
segfault.

jp

[Robert Osfield]

Hi J.P,

On Wed, Oct 7, 2009 at 7:59 AM, J.P. Delport <jpde...@csir.co.za> wrote:
> Debug build still did not provide a nice backtrace, but I've followed the
> crash to
>
> void TextureRectangle::applyTexImage_subload in TextureRectangle.cpp
>
> At the line:
>
> dataPtr = reinterpret_cast<unsigned
> char*>(pbo->getOffset(image->getBufferIndex()));
>
> dataPtr gets assigned 0 and then the glTexSubImage2D call generates the
> segfault.

It's normal for pbo->getOffset() to return a 0, and correct to pass
this to glTexSubImage2D, but only if a PBO is bound, if it isn't then
it will result in a seg fault. Perhaps there is some mistake in the
code that isn't binding the PBO when it should.

Do you get a crash if you use the --texture2D on the osgmovie command line?

Robert.

[J.P. Delport]

Hi Robert,

Robert Osfield wrote:
> Hi J.P,
>
> On Wed, Oct 7, 2009 at 7:59 AM, J.P. Delport <jpde...@csir.co.za> wrote:
>> Debug build still did not provide a nice backtrace, but I've followed the
>> crash to
>>
>> void TextureRectangle::applyTexImage_subload in TextureRectangle.cpp
>>
>> At the line:
>>
>> dataPtr = reinterpret_cast<unsigned
>> char*>(pbo->getOffset(image->getBufferIndex()));
>>
>> dataPtr gets assigned 0 and then the glTexSubImage2D call generates the
>> segfault.
>
> It's normal for pbo->getOffset() to return a 0, and correct to pass
> this to glTexSubImage2D, but only if a PBO is bound, if it isn't then
> it will result in a seg fault. Perhaps there is some mistake in the
> code that isn't binding the PBO when it should.

OK, I'll try to check this too.

>
> Do you get a crash if you use the --texture2D on the osgmovie command line?

No, it runs, but with

Warning: detected OpenGL error 'invalid enumerant' after RenderBin::draw(,)

after every frame.

jp

>
> Robert.
> _______________________________________________
> osg-users mailing list
> osg-...@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.

_______________________________________________

[Robert Osfield]

Hi J.P.,

What hardware and OS are you testing on right now?

On Wed, Oct 7, 2009 at 10:36 AM, J.P. Delport <jpde...@csir.co.za> wrote:
>> It's normal for pbo->getOffset() to return a 0, and correct to pass
>> this to glTexSubImage2D, but only if a PBO is bound, if it isn't then
>> it will result in a seg fault.  Perhaps there is some mistake in the
>> code that isn't binding the PBO when it should.
>
> OK, I'll try to check this too.

I've just done a code review of TextureRectangle.cpp code and it looks
to be binding the PBO and setting the data pointer appropriately. I'm
afraid I haven't yet spotted any lead of what to look into next.

>>
>> Do you get a crash if you use the --texture2D on the osgmovie command
>> line?
>
> No, it runs, but with
>
> Warning: detected OpenGL error 'invalid enumerant' after RenderBin::draw(,)
>
> after every frame.

I upped the granularity of GL error checked via:

export OSG_GL_ERROR_CHECKING=ONCE_PER_ATTRIBUTE

And it then generated the warning after the texture apply, still an
"invalid enumerant". Add more fine grained checks into osg::Texture,
Texture2D and TextureRectangle to further isolate which gl call is the
problem is probably required.

[J.P. Delport]

Hi,

>> It's normal for pbo->getOffset() to return a 0, and correct to pass
>> this to glTexSubImage2D, but only if a PBO is bound, if it isn't then
>> it will result in a seg fault. Perhaps there is some mistake in the
>> code that isn't binding the PBO when it should.
>
> OK, I'll try to check this too.
>
>>
>> Do you get a crash if you use the --texture2D on the osgmovie command
>> line?
>
> No, it runs, but with
>
> Warning: detected OpenGL error 'invalid enumerant' after RenderBin::draw(,)
>
> after every frame.

just some more comments...

I've compared code for
Texture::applyTexImage2D_subload
vs
TextureRectangle::applyTexImage_subload

in the former the result of pbo->getOffset() is never used.

If in TextureRectangle::applyTexImage_subload I leave dataPtr to point
to the image data, it runs the same as --texture2D, i.e.

Warning: detected OpenGL error 'invalid enumerant' after RenderBin::draw(,)

after every frame.

jp

--

[Robert Osfield]

Hi J.P,

On Wed, Oct 7, 2009 at 11:26 AM, J.P. Delport <jpde...@csir.co.za> wrote:
> just some more comments...
>
> I've compared code for
> Texture::applyTexImage2D_subload
> vs
> TextureRectangle::applyTexImage_subload
>
> in the former the result of pbo->getOffset() is never used.
>
> If in TextureRectangle::applyTexImage_subload I leave dataPtr to point to
> the image data, it runs the same as --texture2D, i.e.
>
> Warning: detected OpenGL error 'invalid enumerant' after RenderBin::draw(,)

Could you pinpoint the code you are referring to? Copying and pasting
into an email would be fine, or even line numbers might be OK if you
are working against svn/trunk.

Robert.

[J.P. Delport]

Hi Robert,

Robert Osfield wrote:
> Hi J.P.,
>
> What hardware and OS are you testing on right now?

Debian 32-bit, Nvidia driver.

>
> On Wed, Oct 7, 2009 at 10:36 AM, J.P. Delport <jpde...@csir.co.za> wrote:
>>> It's normal for pbo->getOffset() to return a 0, and correct to pass
>>> this to glTexSubImage2D, but only if a PBO is bound, if it isn't then
>>> it will result in a seg fault. Perhaps there is some mistake in the
>>> code that isn't binding the PBO when it should.
>> OK, I'll try to check this too.
>
> I've just done a code review of TextureRectangle.cpp code and it looks
> to be binding the PBO and setting the data pointer appropriately. I'm
> afraid I haven't yet spotted any lead of what to look into next.
>

Found it. Typo/copy&pasted line in PBO constructor. Target was set to
wrong value and that made the bind fail. Modded file attached.

TextureRectangle now works fine in osgmovie. The world feels better :)

jp

[J.P. Delport]

Hi Robert,

Robert Osfield wrote:
> Hi J.P,
>
> On Wed, Oct 7, 2009 at 11:26 AM, J.P. Delport <jpde...@csir.co.za> wrote:
>> just some more comments...
>>
>> I've compared code for
>> Texture::applyTexImage2D_subload
>> vs
>> TextureRectangle::applyTexImage_subload
>>
>> in the former the result of pbo->getOffset() is never used.
>>
>> If in TextureRectangle::applyTexImage_subload I leave dataPtr to point to
>> the image data, it runs the same as --texture2D, i.e.
>>
>> Warning: detected OpenGL error 'invalid enumerant' after RenderBin::draw(,)
>
> Could you pinpoint the code you are referring to? Copying and pasting
> into an email would be fine, or even line numbers might be OK if you
> are working against svn/trunk.

In Texture::applyTexImage2D_subload Texture.cpp line 2064

glTexSubImage2D( target, 0,
0, 0,
inwidth, inheight,
(GLenum)image->getPixelFormat(),
(GLenum)image->getDataType(),
data - dataMinusOffset + dataPlusOffset);

is called with "data"

line 1987
unsigned char* data = (unsigned char*)image->data();

line 2035, still same function...
const unsigned char* dataPtr = image->data();
GLBufferObject* pbo = image->getOrCreateGLBufferObject(contextID);
if (pbo && !needImageRescale && !useGluBuildMipMaps)
{
state.bindPixelBufferObject(pbo);

dataPtr = reinterpret_cast<unsigned
char*>(pbo->getOffset(image->getBufferIndex()));

dataPtr is set here, but not used at all further in the function.

If you compare this with TextureRectangle::applyTexImage_subload you
will see that dataPtr is set and used there.

So, osgmovie --texture2D now still gives corrupted images, even with the
BufferObject fix applied. It used to work because the binding failed.

Hope I explained better.

jp

>
> Robert.
> _______________________________________________
> osg-users mailing list
> osg-...@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.

_______________________________________________

[Robert Osfield]

Hi J.P,

Thanks for the debugging and the fix in PixelBufferObject constructor.
The fix is now checked in along with the same fix to
PixelDataBufferObject.

On Wed, Oct 7, 2009 at 1:23 PM, J.P. Delport <jpde...@csir.co.za> wrote:
> If you compare this with TextureRectangle::applyTexImage_subload you will
> see that dataPtr is set and used there.

Great detective work. I've just reviewed the code and I had amended
applTexImage_load() correctly, but alas missed making these changes to
the similar code found in applyTexImage_subload.

> So, osgmovie --texture2D now still gives corrupted images, even with the
> BufferObject fix applied. It used to work because the binding failed.
>
> Hope I explained better.

Perfect explanation, lead me straight to the solution of the problem.
I've now applied the appropriate changes to applyTexImage_subload and
tatda' osgmovie --texture2D now woks :-)

Many thanks for you help testing, debugging and fixing this problem.

Cheers,

[Cedric Pinson]

Hi Robert,

I updated to the svn trunk today, and i can notice a crash when quitting
my application. To be sure it was with the new texture manager i defined
USE_NEW_TEXTURE_POOL to 0 and then to 1.

I dont have yet found the problem, but i guess it's linked with my
texture manager, i own some static that reference texture.

The segfault appear when quitting

Program received signal SIGSEGV, Segmentation fault.

#0 0xb6ef7ddf in ?? () from /lib/libc.so.6
#1 0xb5dddc40 in ?? () from //usr//lib/opengl/nvidia/lib/libGLcore.so.1
#2 0xb5dddc40 in ?? () from //usr//lib/opengl/nvidia/lib/libGLcore.so.1
#3 0xb54f2008 in ?? ()
#4 0xb54f2008 in ?? ()
#5 0xb6193d60 in ?? () from //usr//lib/opengl/nvidia/lib/libGLcore.so.1
#6 0xb6fd0bcb in ?? () from /lib/libc.so.6
#7 0xb6fd26e8 in ?? () from /lib/libc.so.6
#8 0xb6fcf469 in ?? () from /lib/libc.so.6
#9 0xb6fcf442 in ?? () from /lib/libc.so.6
#10 0xbfc68254 in ?? ()
#11 0xa7200010 in ?? ()
#12 0x0000001d in ?? ()
#13 0x00000000 in ?? ()

I guess there is something wrong with my texture management and the new
texture pool.

I continue to dig

Cheers,
Cedric

--
+33 659 598 614 Cedric Pinson mailto:cedric...@plopbyte.net
http://www.plopbyte.net

[Cedric Pinson]

Hi Robert,

I cleaned all my singleton before quitting the application. Now i have
the following crash but sometimes it's random. It seems the
TextureObjectManager is deleted before the cache is cleared by Registry
destructor and produce a crash somewhere. I am a bit confuse now, i
continue to track it.
Just for info i use the cache of the registry...

#0 0x081290a8 in ScopedLock (this=0xbf8132b4, m=@0x82d2004)
at /home/mornifle/dev/osg-trunk-svn/debug/lib/../include/OpenThreads/ScopedLock:31
#1 0xb7f87645 in osg::Texture::TextureObjectSet::orphan
(this=0x82d1ff8, to=0x892a078)
at /home/mornifle/dev/osg-trunk-svn/src/osg/Texture.cpp:558
#2 0xb7f87723 in
osg::Texture::TextureObjectManager::releaseTextureObject
(this=0xa594ed90, to=0x892a078)
at /home/mornifle/dev/osg-trunk-svn/src/osg/Texture.cpp:736
#3 0xb7f87796 in osg::Texture::releaseTextureObject (contextID=0,
to=0x892a078)
at /home/mornifle/dev/osg-trunk-svn/src/osg/Texture.cpp:819
#4 0xb7f8780a in osg::Texture::dirtyTextureObject (this=0xb3af02d8)
at /home/mornifle/dev/osg-trunk-svn/src/osg/Texture.cpp:1298
#5 0xb7f87b73 in ~Texture (this=0xb3af02d8)
at /home/mornifle/dev/osg-trunk-svn/src/osg/Texture.cpp:1186
#6 0xb7f7cc2f in ~Texture2D (this=0xb3af02d8)
at /home/mornifle/dev/osg-trunk-svn/src/osg/Texture2D.cpp:52
#7 0x0810f6a2 in osg::Referenced::unref (this=0xb3af02d8)
at /home/mornifle/dev/osg-trunk-svn/debug/lib/../include/osg/Referenced:183
#8 0x0813434c in ~ref_ptr (this=0xb3af0994)
at /home/mornifle/dev/osg-trunk-svn/debug/lib/../include/osg/ref_ptr:33
#9 0x0813436c in ~pair (this=0xb3af0990)
at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g
++-v4/bits/stl_pair.h:73
#10 0x0813437f in __gnu_cxx::new_allocator<std::pair<int const,
osg::ref_ptr<osg::Texture2D> > >::destroy (this=0xbf81343f,
__p=0xb3af0990) at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g
++-v4/ext/new_allocator.h:118
#11 0x081343b4 in std::_Rb_tree<int, std::pair<int const,
osg::ref_ptr<osg::Texture2D> >, std::_Select1st<std::pair<int const,
osg::ref_ptr<osg::Texture2D> > >, std::less<int>,
std::allocator<std::pair<int const, osg::ref_ptr<osg::Texture2D> > >
>::_M_destroy_node (this=0xb4a0a078, __p=0xb3af0980)
at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g
++-v4/bits/stl_tree.h:390
#12 0x0813443e in std::_Rb_tree<int, std::pair<int const,
osg::ref_ptr<osg::Texture2D> >, std::_Select1st<std::pair<int const,
osg::ref_ptr<osg::Texture2D> > >, std::less<int>,
std::allocator<std::pair<int const, osg::ref_ptr<osg::Texture2D> > >
>::_M_erase (this=0xb4a0a078, __x=0xb3af0980)
at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g
++-v4/bits/stl_tree.h:943
#13 0x0813441e in std::_Rb_tree<int, std::pair<int const,
osg::ref_ptr<osg::Texture2D> >, std::_Select1st<std::pair<int const,
osg::ref_ptr<osg::Texture2D> > >, std::less<int>,
std::allocator<std::pair<int const, osg::ref_ptr<osg::Texture2D> > >
>::_M_erase (this=0xb4a0a078, __x=0xb3af0a40)
at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g
++-v4/bits/stl_tree.h:941
#14 0x0813441e in std::_Rb_tree<int, std::pair<int const,
osg::ref_ptr<osg::Texture2D> >, std::_Select1st<std::pair<int const,
osg::ref_ptr<osg::Texture2D> > >, std::less<int>,
std::allocator<std::pair<int const, osg::ref_ptr<osg::Texture2D> > >
>::_M_erase (this=0xb4a0a078, __x=0xb3af0a20)
at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g
++-v4/bits/stl_tree.h:941
#15 0x0813441e in std::_Rb_tree<int, std::pair<int const,
osg::ref_ptr<osg::Texture2D> >, std::_Select1st<std::pair<int const,
osg::ref_ptr<osg::Texture2D> > >, std::less<int>,
std::allocator<std::pair<int const, osg::ref_ptr<osg::Texture2D> > >
>::_M_erase (this=0xb4a0a078, __x=0xb3af0a60)
at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g
++-v4/bits/stl_tree.h:941
#16 0x0813441e in std::_Rb_tree<int, std::pair<int const,
osg::ref_ptr<osg::Texture2D> >, std::_Select1st<std::pair<int const,
osg::ref_ptr<osg::Texture2D> > >, std::less<int>,
std::allocator<std::pair<int const, osg::ref_ptr<osg::Texture2D> > >
>::_M_erase (this=0xb4a0a078, __x=0xb4a09ea0)
at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g
++-v4/bits/stl_tree.h:941
#17 0x0813441e in std::_Rb_tree<int, std::pair<int const,
osg::ref_ptr<osg::Texture2D> >, std::_Select1st<std::pair<int const,
osg::ref_ptr<osg::Texture2D> > >, std::less<int>,
std::allocator<std::pair<int const, osg::ref_ptr<osg::Texture2D> > >
>::_M_erase (this=0xb4a0a078, __x=0xb4a09e80)
at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g
++-v4/bits/stl_tree.h:941
#18 0x0813441e in std::_Rb_tree<int, std::pair<int const,
osg::ref_ptr<osg::Texture2D> >, std::_Select1st<std::pair<int const,
osg::ref_ptr<osg::Texture2D> > >, std::less<int>,
std::allocator<std::pair<int const, osg::ref_ptr<osg::Texture2D> > >
>::_M_erase (this=0xb4a0a078, __x=0xb4a006b8)
at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g
++-v4/bits/stl_tree.h:941
#19 0x0813446e in ~_Rb_tree (this=0xb4a0a078)
at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g
++-v4/bits/stl_tree.h:585
#20 0x081344c1 in ~map (this=0xb4a0a078)
at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4/bits/stl_map.h:92
#21 0x08134cff in ~DeckNode (this=0xb4a09ff8)
at /home/mornifle/dev/pokme-modelview/src/Deck.cpp:45
#22 0x0810f6a2 in osg::Referenced::unref (this=0xb4a09ff8)
at /home/mornifle/dev/osg-trunk-svn/debug/lib/../include/osg/Referenced:183
#23 0x0810f6c0 in ~ref_ptr (this=0xb4a0eed4)
at /home/mornifle/dev/osg-trunk-svn/debug/lib/../include/osg/ref_ptr:33
#24 0xb75615b7 in ~pair (this=0xb4a0eed4)
at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g
++-v4/bits/stl_pair.h:73
#25 0xb75615e0 in ~pair (this=0xb4a0eed0)
at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g
++-v4/bits/stl_pair.h:73
#26 0xb756164b in __gnu_cxx::new_allocator<std::pair<std::string const,
std::pair<osg::ref_ptr<osg::Object>, double> > >::destroy
(this=0xbf81364b, __p=0xb4a0eed0)
at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g
++-v4/ext/new_allocator.h:118
#27 0xb7561690 in std::_Rb_tree<std::string, std::pair<std::string
const, std::pair<osg::ref_ptr<osg::Object>, double> >,
std::_Select1st<std::pair<std::string const,
std::pair<osg::ref_ptr<osg::Object>, double> > >,
std::less<std::string>, std::allocator<std::pair<std::string const,
std::pair<osg::ref_ptr<osg::Object>, double> > > >::_M_destroy_node
(this=0x8239650, __p=0xb4a0eec0)
at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g
++-v4/bits/stl_tree.h:390
#28 0xb7561726 in std::_Rb_tree<std::string, std::pair<std::string
const, std::pair<osg::ref_ptr<osg::Object>, double> >,
std::_Select1st<std::pair<std::string const,
std::pair<osg::ref_ptr<osg::Object>, double> > >,
std::less<std::string>, std::allocator<std::pair<std::string const,
std::pair<osg::ref_ptr<osg::Object>, double> > > >::_M_erase
(this=0x8239650, __x=0xb4a0eec0)
at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g
++-v4/bits/stl_tree.h:943
#29 0xb7561765 in std::_Rb_tree<std::string, std::pair<std::string
const, std::pair<osg::ref_ptr<osg::Object>, double> >,
std::_Select1st<std::pair<std::string const,
std::pair<osg::ref_ptr<osg::Object>, double> > >,
std::less<std::string>, std::allocator<std::pair<std::string const,
std::pair<osg::ref_ptr<osg::Object>, double> > > >::clear
(this=0x8239650) at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g
++-v4/bits/stl_tree.h:697
#30 0xb75617d9 in std::map<std::string,
std::pair<osg::ref_ptr<osg::Object>, double>, std::less<std::string>,
std::allocator<std::pair<std::string const,
std::pair<osg::ref_ptr<osg::Object>, double> > > >::clear
(this=0x8239650) at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g
++-v4/bits/stl_map.h:582
#31 0xb754252f in osgDB::Registry::clearObjectCache (this=0x8239488)
at /home/mornifle/dev/osg-trunk-svn/src/osgDB/Registry.cpp:2170
#32 0xb754281b in osgDB::Registry::destruct (this=0x8239488)
at /home/mornifle/dev/osg-trunk-svn/src/osgDB/Registry.cpp:393
#33 0xb754c678 in ~Registry (this=0x8239488)
at /home/mornifle/dev/osg-trunk-svn/src/osgDB/Registry.cpp:372
#34 0x0810f6a2 in osg::Referenced::unref (this=0x8239488)
at /home/mornifle/dev/osg-trunk-svn/debug/lib/../include/osg/Referenced:183
#35 0xb7562e86 in ~ref_ptr (this=0xb7599730)
at /home/mornifle/dev/osg-trunk-svn/include/osg/ref_ptr:33
#36 0xb6e57ed1 in exit () from /lib/libc.so.6
(gdb) bt
#0 0x081290a8 in ScopedLock (this=0xbf8132b4, m=@0x82d2004)
at /home/mornifle/dev/osg-trunk-svn/debug/lib/../include/OpenThreads/ScopedLock:31
#1 0xb7f87645 in osg::Texture::TextureObjectSet::orphan
(this=0x82d1ff8, to=0x892a078)
at /home/mornifle/dev/osg-trunk-svn/src/osg/Texture.cpp:558
#2 0xb7f87723 in
osg::Texture::TextureObjectManager::releaseTextureObject
(this=0xa594ed90, to=0x892a078)
at /home/mornifle/dev/osg-trunk-svn/src/osg/Texture.cpp:736
#3 0xb7f87796 in osg::Texture::releaseTextureObject (contextID=0,
to=0x892a078)
at /home/mornifle/dev/osg-trunk-svn/src/osg/Texture.cpp:819
#4 0xb7f8780a in osg::Texture::dirtyTextureObject (this=0xb3af02d8)
at /home/mornifle/dev/osg-trunk-svn/src/osg/Texture.cpp:1298
#5 0xb7f87b73 in ~Texture (this=0xb3af02d8)
at /home/mornifle/dev/osg-trunk-svn/src/osg/Texture.cpp:1186
#6 0xb7f7cc2f in ~Texture2D (this=0xb3af02d8)
at /home/mornifle/dev/osg-trunk-svn/src/osg/Texture2D.cpp:52
#7 0x0810f6a2 in osg::Referenced::unref (this=0xb3af02d8)
at /home/mornifle/dev/osg-trunk-svn/debug/lib/../include/osg/Referenced:183
#8 0x0813434c in ~ref_ptr (this=0xb3af0994)
at /home/mornifle/dev/osg-trunk-svn/debug/lib/../include/osg/ref_ptr:33
#9 0x0813436c in ~pair (this=0xb3af0990)
at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g
++-v4/bits/stl_pair.h:73
#10 0x0813437f in __gnu_cxx::new_allocator<std::pair<int const,
osg::ref_ptr<osg::Texture2D> > >::destroy (this=0xbf81343f,
__p=0xb3af0990) at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g
++-v4/ext/new_allocator.h:118
#11 0x081343b4 in std::_Rb_tree<int, std::pair<int const,
osg::ref_ptr<osg::Texture2D> >, std::_Select1st<std::pair<int const,
osg::ref_ptr<osg::Texture2D> > >, std::less<int>,
std::allocator<std::pair<int const, osg::ref_ptr<osg::Texture2D> > >
>::_M_destroy_node (this=0xb4a0a078, __p=0xb3af0980)
at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g
++-v4/bits/stl_tree.h:390
#12 0x0813443e in std::_Rb_tree<int, std::pair<int const,
osg::ref_ptr<osg::Texture2D> >, std::_Select1st<std::pair<int const,
osg::ref_ptr<osg::Texture2D> > >, std::less<int>,
std::allocator<std::pair<int const, osg::ref_ptr<osg::Texture2D> > >
>::_M_erase (this=0xb4a0a078, __x=0xb3af0980)
at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g
++-v4/bits/stl_tree.h:943
#13 0x0813441e in std::_Rb_tree<int, std::pair<int const,
osg::ref_ptr<osg::Texture2D> >, std::_Select1st<std::pair<int const,
osg::ref_ptr<osg::Texture2D> > >, std::less<int>,
std::allocator<std::pair<int const, osg::ref_ptr<osg::Texture2D> > >
>::_M_erase (this=0xb4a0a078, __x=0xb3af0a40)
at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g
++-v4/bits/stl_tree.h:941
#14 0x0813441e in std::_Rb_tree<int, std::pair<int const,
osg::ref_ptr<osg::Texture2D> >, std::_Select1st<std::pair<int const,
osg::ref_ptr<osg::Texture2D> > >, std::less<int>,
std::allocator<std::pair<int const, osg::ref_ptr<osg::Texture2D> > >
>::_M_erase (this=0xb4a0a078, __x=0xb3af0a20)
at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g
++-v4/bits/stl_tree.h:941
#15 0x0813441e in std::_Rb_tree<int, std::pair<int const,
osg::ref_ptr<osg::Texture2D> >, std::_Select1st<std::pair<int const,
osg::ref_ptr<osg::Texture2D> > >, std::less<int>,
std::allocator<std::pair<int const, osg::ref_ptr<osg::Texture2D> > >
>::_M_erase (this=0xb4a0a078, __x=0xb3af0a60)
at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g
++-v4/bits/stl_tree.h:941
#16 0x0813441e in std::_Rb_tree<int, std::pair<int const,
osg::ref_ptr<osg::Texture2D> >, std::_Select1st<std::pair<int const,
osg::ref_ptr<osg::Texture2D> > >, std::less<int>,
std::allocator<std::pair<int const, osg::ref_ptr<osg::Texture2D> > >
>::_M_erase (this=0xb4a0a078, __x=0xb4a09ea0)
at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g
++-v4/bits/stl_tree.h:941
#17 0x0813441e in std::_Rb_tree<int, std::pair<int const,
osg::ref_ptr<osg::Texture2D> >, std::_Select1st<std::pair<int const,
osg::ref_ptr<osg::Texture2D> > >, std::less<int>,
std::allocator<std::pair<int const, osg::ref_ptr<osg::Texture2D> > >
>::_M_erase (this=0xb4a0a078, __x=0xb4a09e80)
at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g
++-v4/bits/stl_tree.h:941
#18 0x0813441e in std::_Rb_tree<int, std::pair<int const,
osg::ref_ptr<osg::Texture2D> >, std::_Select1st<std::pair<int const,
osg::ref_ptr<osg::Texture2D> > >, std::less<int>,
std::allocator<std::pair<int const, osg::ref_ptr<osg::Texture2D> > >
>::_M_erase (this=0xb4a0a078, __x=0xb4a006b8)
at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g
++-v4/bits/stl_tree.h:941
#19 0x0813446e in ~_Rb_tree (this=0xb4a0a078)
at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g
++-v4/bits/stl_tree.h:585
#20 0x081344c1 in ~map (this=0xb4a0a078)
at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4/bits/stl_map.h:92
#21 0x08134cff in ~DeckNode (this=0xb4a09ff8)
at /home/mornifle/dev/pokme-modelview/src/Deck.cpp:45
#22 0x0810f6a2 in osg::Referenced::unref (this=0xb4a09ff8)
at /home/mornifle/dev/osg-trunk-svn/debug/lib/../include/osg/Referenced:183
#23 0x0810f6c0 in ~ref_ptr (this=0xb4a0eed4)
at /home/mornifle/dev/osg-trunk-svn/debug/lib/../include/osg/ref_ptr:33
#24 0xb75615b7 in ~pair (this=0xb4a0eed4)
at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g
++-v4/bits/stl_pair.h:73
#25 0xb75615e0 in ~pair (this=0xb4a0eed0)
at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g
++-v4/bits/stl_pair.h:73
#26 0xb756164b in __gnu_cxx::new_allocator<std::pair<std::string const,
std::pair<osg::ref_ptr<osg::Object>, double> > >::destroy
(this=0xbf81364b, __p=0xb4a0eed0)
at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g
++-v4/ext/new_allocator.h:118
#27 0xb7561690 in std::_Rb_tree<std::string, std::pair<std::string
const, std::pair<osg::ref_ptr<osg::Object>, double> >,
std::_Select1st<std::pair<std::string const,
std::pair<osg::ref_ptr<osg::Object>, double> > >,
std::less<std::string>, std::allocator<std::pair<std::string const,
std::pair<osg::ref_ptr<osg::Object>, double> > > >::_M_destroy_node
(this=0x8239650, __p=0xb4a0eec0)
at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g
++-v4/bits/stl_tree.h:390
#28 0xb7561726 in std::_Rb_tree<std::string, std::pair<std::string
const, std::pair<osg::ref_ptr<osg::Object>, double> >,
std::_Select1st<std::pair<std::string const,
std::pair<osg::ref_ptr<osg::Object>, double> > >,
std::less<std::string>, std::allocator<std::pair<std::string const,
std::pair<osg::ref_ptr<osg::Object>, double> > > >::_M_erase
(this=0x8239650, __x=0xb4a0eec0)
at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g
++-v4/bits/stl_tree.h:943
#29 0xb7561765 in std::_Rb_tree<std::string, std::pair<std::string
const, std::pair<osg::ref_ptr<osg::Object>, double> >,
std::_Select1st<std::pair<std::string const,
std::pair<osg::ref_ptr<osg::Object>, double> > >,
std::less<std::string>, std::allocator<std::pair<std::string const,
std::pair<osg::ref_ptr<osg::Object>, double> > > >::clear
(this=0x8239650) at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g
++-v4/bits/stl_tree.h:697
#30 0xb75617d9 in std::map<std::string,
std::pair<osg::ref_ptr<osg::Object>, double>, std::less<std::string>,
std::allocator<std::pair<std::string const,
std::pair<osg::ref_ptr<osg::Object>, double> > > >::clear
(this=0x8239650) at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g
++-v4/bits/stl_map.h:582
#31 0xb754252f in osgDB::Registry::clearObjectCache (this=0x8239488)
at /home/mornifle/dev/osg-trunk-svn/src/osgDB/Registry.cpp:2170
#32 0xb754281b in osgDB::Registry::destruct (this=0x8239488)
at /home/mornifle/dev/osg-trunk-svn/src/osgDB/Registry.cpp:393
#33 0xb754c678 in ~Registry (this=0x8239488)
at /home/mornifle/dev/osg-trunk-svn/src/osgDB/Registry.cpp:372
#34 0x0810f6a2 in osg::Referenced::unref (this=0x8239488)
at /home/mornifle/dev/osg-trunk-svn/debug/lib/../include/osg/Referenced:183
#35 0xb7562e86 in ~ref_ptr (this=0xb7599730)
at /home/mornifle/dev/osg-trunk-svn/include/osg/ref_ptr:33
#36 0xb6e57ed1 in exit () from /lib/libc.so.6

Cheers,
Cedric

--
+33 659 598 614 Cedric Pinson mailto:cedric...@plopbyte.net
http://www.plopbyte.net

[Eric Deko]

pankajnagarkoti80 wrote:
> The benefit the GL object pools provide is that we can scale up the
> scene graph in main memory without blowing OpenGL driver and GPU
> memory as we would do without the new pools.

I agree, that is really a great benifit especially with the GL users.

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

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

[Cedric Pinson]

Hi again,

ok i found my mistake and it could help other people that have a strange
behaviour when quitting. I make a small code to reproduce the problem.
At the end i did
myviewer.setSceneData(0);
in order to remove scene. With the new texture manager it produces this
valgrind output in attached file. I did not think it was bad to do that.
anyway if this post can save time for other people...

#include <osg/ref_ptr>
#include <osgDB/ReadFile>
#include <osgDB/Registry>
#include <osgViewer/Viewer>
#include <osg/StateSet>
#include <osgText/Text>
#include <osg/Texture2D>

int main(int argc, char** argv)
{
osg::ref_ptr<osg::Group> grp = new osg::Group;
osgViewer::Viewer myviewer;
myviewer.setSceneData(grp);

osg::ref_ptr<osg::Geode> geode = new osg::Geode;
osg::ref_ptr<osgText::Text> chipsText = new osgText::Text;
std::string fontName = "../data/Vera.ttf";
int size = 20;
osg::Vec3 pos(0,0,0);
osg::ref_ptr<osgText::Font> font =
osgText::readFontFile(fontName.c_str());
chipsText->setFont(font);
chipsText->setText("blabla");
geode->addDrawable(chipsText);
grp->addChild(geode);

myviewer.realize();
myviewer.run();
myviewer.setSceneData(0);
return 0;
}

--
+33 659 598 614 Cedric Pinson mailto:cedric...@plopbyte.net
http://www.plopbyte.net

On Thu, 2009-10-08 at 15:22 +0200, Cedric Pinson wrote:

[Robert Osfield]

Hi Cedric,

Thanks for keep on digging into this problem. I don't think this is a
bug in your code, rather you've just set up a set of circumstances
that the normal clean up is circumvented and an errors occurs. If
possible we should find a way of avoid the problem in full range of
usage.

Does the little example app you provided in your email reproduce the
crash on exit? Could we use this as a unit test?

Robert.

[Cedric Pinson]

Hi Robert,

Yes you will be able to reproduce the valgrind output with the the code
sample in the email.

Cheers,
Cedric

--
+33 659 598 614 Cedric Pinson mailto:cedric...@plopbyte.net
http://www.plopbyte.net

[Robert Osfield]

Hi Cedric,

As another lead into this problem I've found that the osgcatch example
now hangs on exit when it's run multi-threaded. All the other
examples exit fine, but osgcatch hangs inside th new TextureObject
clean up code at a mutex that seems to be left locked by another
thread. I don't know why this is, but clearly there is something
fragile in the clean that will need addressing.

[Cedric Pinson]

Hi Robert,

I think to address the problem but i need to finish other stuff before.
A way i thought to resolve that should be to add to osgViewer a cleanup
method that would release all singleton and data that make it safe to
quit an application. A method like that could be called automatically by
osgViewer destructor or by hand maybe.
It's not clear enough to me how the cleanup could be, but maybe it could
be a way to clean the exit.

Cheers,
Cedric

--
+33 659 598 614 Cedric Pinson mailto:cedric...@plopbyte.net
http://www.plopbyte.net

[Robert Osfield]

Hi Cedric,

osgViewer/core OSG should already have all the mechanisms available to
do clean up of the scene graph and associated OpenGL objects correctly
- and in fact it's possibly these existing mechanisms that are causing
the failure in question.  I suspect the solution will come from
studying exactly what is happening and when during the destruction
phases of the graphics threads, graphics context, scene graph and
viewer, something small is likely amiss - the challenging is
pinpointing exactly what this "something small" is...

Once I've progressed the OpenGL ES 2.0 port a bit further I'll revisit
this issue, my expectation is that it'll just require a couple of
hours of TLC.

Robert.