(Sorry if this ends up twice. I posted something similar yesterday but
it must've disappeared)
Gerrit Voss wrote:
> Hi,
>
> On Sat, 2008-11-22 at 17:24 -0600, Carsten Neumann wrote:
>> 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).
You need the '/useenv' argument to make it pick up the local env. Using
that it works fine. (I recall posting a ticket ages ago with a cmd-file
containing that which simplified OpenSG-development on Windows.)
>>> 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:
[snip - static storage destruction uses same queue as atexit()]
>> 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.
I assume that just allowing the MTRecPtr to cleanup the material and
removing the separate cleanup handler is not an option, as it must be
destroyed before osgexit is run (which we can't be sure of)?
IMHO, requiring explicit osgexit is an ok change for 2.0, and it might
be for the best anyway. It will force app writers to be explicit about
their cleanup sequence, which does cause additional effort. My
experience tells me it's probably better to clean things up explcitly
than rely on the initialization order, especially when things get advanced.
(We used Loki's singleton-with-longevity for a number of managers, which
worked well most of the time, but when it didn't, it wasn't fun..)
Cheers,
/Marcus
-------------------------------------------------------------------------
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
