Hi Thorsten,
Thanks for your reply and for taking a careful look at this. As far as I
know I'm running pure and current git.
I instrumented visual_enviro.cxx a bit to see what/where "sampleGroup" is
being set. It is indeed being set from inside FGClouds::Init() in
fgclouds.cxx, line #78 makes the actual call.
The code seems pretty definite that it would execute here, so it's odd that
you are getting NULL there ... unless the sgmgr->find() call is returning
null for you? Or if like you say, somehow our source trees have diverged.
But I do think I'm 100% current with git.
I will go ahead and remove the call to delete sampleGroup in the destructor
unless someone has any last minute objections.
Thanks,
Curt.
On Tue, May 3, 2011 at 12:09 PM, ThorstenB <[email protected]> wrote:
> On 03.05.2011 17:05, Curtis Olson wrote:
> > My git build here recently started crashing on exit again. I've been
> > looking into it and I think I traced it to
> > simgear/environment/visual_enviro.cxx in the destructor around line
> > #190. This module builds up sound effects for thunder/lighting, in a
> > "weather" sample group. The module keeps a pointer to the sample group
> > and then tries to delete it in the destructor.
> Really weird. Are you running pure GIT - or also some local
> enhancements? The sampleGroup pointer is always NULL on my system - and
> it seems we currently don't even create a "weather" sample group
> anywhere in the current code. So, *possibly* the root cause of your
> issues could be completely elsewhere (such as memory corruption issue
> overwriting the "sampleGroup" variable...).
> Also, "sampleGroup" isn't even used within the visual_enviro module - so
> we could probably even drop the pointer from the sources.
>
> > Anyway, would it be safe to remove this call to delete in the
> > visual_enviro.cxx destructor and depend on the sound manager destructor
> > to clean it up? Or should we try to do something fancier?
> If "sampleGroup" was used, then it indeed should _not_ be removed in the
> ~SGEnviro. The SGEnviro object doesn't create the object itself - it's
> just given a pointer to an object from the outside. And such object
> would/should be owned by the sound manager. So, I think it's a good idea
> to remove the "if (samplegroup) delete ..." line in any case.
>
> cheers,
> Thorsten
>
>
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today. Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> Flightgear-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
--
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
