Hi,
On Sat, 2008-11-22 at 17:24 -0600, Carsten Neumann wrote:
> Hello Marcus,
>
> Marcus Lindblom wrote:
> > Carsten Neumann wrote:
> >> alright, on windows (vs 2008 express) I can reproduce it (r1577).
> >> BTW is there a way to start the debugger from a command line (similar
> >> like doing gdb ./testSimpleSceneManager)? It is a bit painful having to
> >> create a new project and coax it into debugging an existing program that
> >> it did not really build itself.
> >
> > Yup .. Do 'devenv /?' and see the options,
>
> Thanks for the tip, but I don't think I have that program.
>
> > alternatively you can do
> > 'attach to process' from the debug menu in the IDE. I think you also can
> > create an empty project and enter 'testsimplescenemanager' in the debug
> > settings on the project then just start it in debug mode (i.e. F5).
>
> that is sort of what I'm doing, but it requires that I set up the
> environment to find libs in the IDE, instead of just using the
> environment on my command line. Hopefully this was a one time process
> now that I've gone though it ;)
this is strange, I'm pretty sure starting devenv from cygwin takes the
correct settings from there (at least the non express versions do).
> >
> > Perhaps some tracing on destructor calls might help.
>
> ok, I've found the problem. The default materials are held by variables
> defined in OSGMatrial.cpp as:
>
> static SimpleMaterialMTRecPtr _defaultMaterial;
> static SimpleMaterialMTRecPtr _defaultUnlitMaterial;
>
> which means of course that the C++ runtime will run the d'tors when the
> program is exiting and AFAICS before the atexit handlers are called.
> Now the following happens:
> - _defaultMatarial is destroyed by its d'tor (which does not set the
> member _pObj to NULL).
> - osgExit is run as an atexit handler
> - the registered subRefDefaultMaterial pre factory exit function is run,
> operating on the already destroyed _defaultMaterial and doing:
>
> bool subRefDefaultMaterial (void)
> {
> _defaultMaterial = NULL;
>
> return true;
> }
>
> - the assignment operator checks _pObj against NULL and decreases the
> ref count
> - that crashes because the pointed to object is gone already
>
> The second part can be fixed by having the RefCountPtr d'tor set _pObj
> to NULL, but that only papers over the real problem that the atexit
> handler runs after _defaultMaterial itself is already destroyed.
>
> Maybe I have too much trust in valgrind, but since it did not complain
I have to admit I never ran tests that did not call osgExit explicitly.
> I'm still wondering if the order of d'tors for global static objects and
> atexit handlers is different (and probably implementation
> defined/undefined so we should not rely on it anyways) ?
3.6.3 Termination / 3 solves the mystery:
If a function is registered with atexit (see <cstdlib>, 18.3) then
following the call to exit, any objects with static storage duration
initialized prior to the registration of that function shall not be
destroyed until the registered function is called from the termination
process and has completed. For an object with static storage duration
constructed after a function is registered with atexit, then following
the call to exit, the registered function is not called until the
execution of the object’s destructor has completed. If atexit is called
during the construction of an object, the complete object to which it
belongs shall be destroyed before the registered function is called.
> Anybody got a good idea ?
The above says basically our use of atexit is wrong. I'm fine with going
back to explicit osgExit calls (I do that anyway). The other option
is to register a callback that removes subRefDefaultMaterial from the
pre factory exit functions.
kind regards,
gerrit
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
