(Most of this written last night before bed)
Hi all, commenting out code in the destructor won't help, as the problem is
being set-up much earlier, while FGFS is still in the initialization stages
(dt == 0) : in debug, there is a fatal assert on SGSoundSample::freedata,
being called by SGSoundMgr::requestBuffer, line 429), itself being called
from SGSampleGroup::update (line 104), rumble.wav, ultimately going back up
the call chain to fgOSMainLoop.
I suspect the exit bug in Release is when it starts freeing stuff that's not
there to be freed. I say suspect 'cause I can't get there in Debug, as it
fails before finishing complete initialization.
the alutinit++ stuff is wrong : alutinit is at 2 at the time the destructor
checks it, thus never calling alutExit (not that it matters, alutInit does
nothing but set a flag variable in the variant we use)
there is one incrementation too much in there, and since it can only be
initialized once, why track a number ?
I believe SoundManager::load might be where it's all happening, or starting
to happen.
You do use a weird param setup, assigning unitialized values from pointers
to stack variables then passing the address of the stack variables as
params, only to write them back in the pointers at the end :)
It returns garbage on trying to load the ATC voice, maybe because there is
no valid AL context as the (internal) message error says, before the catch
code gets rid of it. Doesn't assert there 'though, churns on until it gets
to rumble.wav.
Why is SoundManager::load a static member function ? it's never called that
way, and always as a member function, so why ? (not major, but bad form)
Also, if (_data != NULL) { delete[] _data; _data = NULL; } in free_data() in
sample_openal.hxx is the offending party (in debug). I believe delete[] is
the problem, _data not explicitly being an array (and not using new in any
shape or form)
Will look more into it, but if more people, not just on windows, could take
some time to run the new sound system in debug, we might root out a few bugs
in it while we're at it.
Could you guys build in debug and run it through and see what you come up
with ?
I'm sure Erik could use the help.
Hope this helps, will investigate further,
Cheers,
Nic
On Tue, Oct 13, 2009 at 4:05 AM, Erik Hofman <e...@ehofman.com> wrote:
> Vivian Meazza wrote:
>
> > Nope, that doesn't fix it - still get crash on exit. But I no longer get
> > sound stopping when I change window size at runtime.
>
> You might want to comment out some code in SGSoundMgr::~SGSoundMGr to
> see what exactly might cause it.
>
> Erik
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
--
Be Kind.
Remember, everyone is fighting a hard battle.
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
