Greetings.

Consider these lines from Examples/Simple/clusterserver.cpp:

    // Declared at file scope:
    OSG::GLUTWindowRefPtr window;
    OSG::ClusterServer    *server;

    // in main:
    window = OSG::GLUTWindow::create();
    server = new OSG::ClusterServer(window,name,connectionType,address);
    // ...
    delete server;
    window = NULL;

The file scope holds a reference-counted pointer to the GLUTWindow.
The main function creates the window, assigns the pointer, and passes
it to the ClusterServer constructor.

The ClusterServer constructor accepts a naked pointer and wraps it in
its own internal reference-counted pointer (WindowUnrecPtr _window).

Do we now have two uncoordinated reference counts to the underlying
GLUTWindow object, with the threat of calling its destructor twice as
these reference counts independently return to zero?  Or is there
something happening behind the scene to prevent that?

The reason I ask is that my program is crashing in its exit routines,
and I suspect it may be because a destructor is getting called twice,
from two uncoordinated reference counted pointers.

My program follows essentially the same logic as the demo, except that
I have no file scope variables: I hold the window and server in data
members of a class.  Trouble ensues in the close() function for this
class.  This happens before osgExit() :

    // Class data members:
    OSG::PassiveWindowRecPtr   m_Window;
    OSG::ClusterServer       * m_ClusterServer;

    // Creating the window and server:
    m_Window        = OSG::PassiveWindow::create();
    m_ClusterServer = new OSG::ClusterServer (m_Window, ...);

    // Closing:
    delete m_ClusterServer;  // OK
    m_Window = NULL;         // Crash -- uncaught exception

Unhandled exception ...
Access violation reading location 0xffffffffffffffff.

OSG::RecordedRefCountPolicy::subRef(OSG::FieldContainer * const 
objectP=0x00000000032a1800)  Line 66    C++

Thanks for any insights.

-- 

Ted Hall


------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Reply via email to