Hi Adrian,

I don't think this is an OSG bug, rather your application/plugin isn't
managing the clean up of graphics contexts in the right order.  Doing
a ref on the PerContextProgram object shouts out memory leak, which
I'd guess is you way of preventing proper cleanup.

It should possible to manage the clean up correctly without resorting
to these hacks, I don't know enougth about your particular
application/OSG usage to spot what you are doing wrong.  Might I
suggest a separate thread on this issue as it's really about correct
OSG usage rather than the 2.8. release.

Cheers,
Robert.

On Mon, Feb 9, 2009 at 7:16 AM, Adrian Egli OpenSceneGraph (3D)
<[email protected]> wrote:
> Hi Robert,
>
> I came around a long nightly tests, because i have a strange behaviour in
> our application w.r.t. to closing. For some models it raise an access
> violation error, for some not. now i worked out the problem we have.
>
> It's only raised (0x00005 : access violation) :
> - when we append a slave at run time and remove it
> - when we have a shader attached (user shader) osg::Programm
>
> the code for adding removing the slave, just a look at the attachement
> (GuiEventHandler.cpp)
> releaseGLObjects then the error / crash can avoided.
>
> the problem comes from invalid pointer in _pcpList[x] = 0; the unref gets
> crashed. because the objects
> is still invalid, removed, in other program, or somewhere else or the
> initalization, or .. is not correct
> but only we renderer slave, and removed the slave (context) otherwise it
> works ok.
>
> i don't yet know where the bugs come from. or how we have to fix it. what
> does the _pcpList store? shared
> objects ?
>
>
> /adrian
>
>
>
> class WebaddonProgram : public osg::Program {
>     public:
>         virtual void releaseGLObjects(osg::State* state=0) const {
>
>             for( unsigned int i=0; i < _shaderList.size(); ++i )
>             {
>                 if (_shaderList[i].valid())
> _shaderList[i]->releaseGLObjects(state);
>             }
>
>             // begin hack (FIX)
>             // i don't understand why this has to be done by a such hack.
>             // but we believe that under full screen the OSG engine does't
> right copy
>             // the pcp buffer (we are running under single threaded)
>             for (unsigned int i(0);i<_pcpList.size();i++ ) {
>                 _pcpList[i]->ref();
>             }
>             // end hack
>
>
>             osg::buffered_value<double> ARR;
>             if (!state) {
>                 // FIX _pcpList.setAllElementsTo(0);
>             } else {
>                 unsigned int contextID = state->getContextID();
>                 // FIX _pcpList[contextID] = 0; (FULL SCREEN BUG)
>             }
>         }
> };
>
>
> 2009/2/8 Robert Osfield <[email protected]>
>>
>> Hi Paul,
>>
>> The fix is now checked into svn/trunk and OSG-2.8.
>>
>> Robert.
>>
>> On Sun, Feb 8, 2009 at 5:35 PM, Robert Osfield <[email protected]>
>> wrote:
>> > Hi Paul,
>> >
>> > After a tea break I got back on the horse and tracked the problem down
>> > to the osgText::Text::computeGlyphRepresentation() skipping every
>> > second repeated \n due to the way the if(){}else{} were set up.  I
>> > moved the end of lip skip to prevent this.  Changed file attached.  I
>> > can't check the file in right now, I'll try later on.
>> >
>> > Robert.
>> >
>> _______________________________________________
>> osg-users mailing list
>> [email protected]
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
>
> --
> ********************************************
> Adrian Egli
>
> _______________________________________________
> osg-users mailing list
> [email protected]
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Reply via email to