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 ;)
>> osgExit does not help, but gives a different stack trace that goes to
>> the d'tor of a std::vector (size 1270) of boost::functions, all of them
>> appear to be empty. The crash is in destroying these boost::functions.
>> Dunno looks like a red herring to me.
>
> When I was looking in the debugger it was trying to do stuff on a null
> object. IIRC it was trying to clean up the default material. There is a
> function for doing explicitly that (which is registed using a
> boost::function) and I don't think it used ref-counts, it just called
> delete (which invites problems, I try to avoid it like the plauge, which
> has worked well). So, anyway, I do suspect that that happens twice,
> although I didn't have time to pursue it further yesterday.
>
>> strange, when looking at this in the debugger the most notable thing is
>> that the _type object seems to be botched, it has a null prototype
>> pointer and no strings describing it, weird. I'll look some more into
>> this tomorrow unless of course someone beats me to it ;)
>
> My guess is that the object is being destroyed twice. (I'm always
> suspicious of 0xfeeefeee patterns and numbers around 3.2*10^9 .. :)
> At least when doing a debug build, you get those kind of patterns in
> freed memory.
>
> 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'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) ?
Anybody got a good idea ?
Thanks,
Carsten
-------------------------------------------------------------------------
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
