0
0

Hi,

like the others reporting in this forum, I’ve suffered the error (crash) when calling FMOD::System::release().

It always failed at the same location. With your latest dev build, I’ve been able to trace with more details the location of the problem (thanks to your debug libs):

=========================================================================

function FMOD::OutputDSounds::update

in this function, there are a number of calls to (in order):

  • FMOD::SystemI::get3DNumListeners
  • FMOD::SystemI::get3DListenerAttributes
  • FMOD::SystemI::get3DSettings

then a series of tests on variables rooloffscale, distancescale, dopplerscale

then erase the struct dsListenerParams

then a call to a function (virtual function?) that leads to an error message if failed:

"IDirectSoundListener::SetAllParameters returned errcode %08X"

then call FMOD::ChannelPool::getNumChannels
then call FMOD::ChannelPool::getChannel (in a loop)

AND THEN:

right after the loop that call getChannel above, there is a call to a function (in the debugger, this+0x244 seems to be a pointer to a class, which seems to have a vTbl and the function calls this vTbl+0x44). The vTbl seems to be pointing to 0! maybe an error (a class without a virtual destructor somewhere)??

So the code fails at this exact location everytime!

with fmodexD.dll, this is happening at 006C8F97 (DLL base listed at 006C0000 in the debugger).

Hope this helps!

John

  • You must to post comments
0
0

so you’re calling fmod functions from different threads? If so, that’s your problem. We repeatedly say not to do that, in fact the latest version spams a warning if you do and i’ve made it bigger and bolder in the documentation.

  • You must to post comments
0
0

Hi Bret,

it is still crashing with .37 and it looks like it is the same error. It will be hard to provide a "sample/test" project though as our soundmanager class is tied up with many other things in our project.

Is there any "trace enabled" "debug" version I could try for you? from the "trace" I’ve done in the debugger, it should be quite "locatable" in your code: either your code is calling a virtual function for class, which pointer to its vtable in the other class is 0, or, you are calling a pointer that has been set to 0 before. For the later, a simple test of the pointer before calling the function should help trap the issue, in the former I suspect a destructor called too soon somewhere like this:

delete m_ptr_to_my_class;

m_ptr_to_my_class = 0; <—- missing line leaving something not expected.

Hope this helps!

  • You must to post comments
0
0

Hi Bret,

no, not from a different thread, the same thread. I was mentioning "thread" as the update loop of the application is in a thread. BUT, when I don’t call FMOD:Update() at all, so just starting it, and when the application quits closing it with the C++ code above, it crashes as well, in the same function, just at a different location (right in the code block before the other one).

This is all taking place in a code of yours that call "direct sound update" when it closes.

Let me explain the software architecture as it is implemented right now in order to make sure all is correct thread wise for you:

1) application.exe binds to an application.dll
2) application.dll contains the code to create 1 instance of our main class
3) the main class uses 1 instance of our soundclass
4) our sound class init the FMOD (code above) in a function "init" called by our main class when the main class is called to init from the DLL which is called to init from the .exe
5) the sound class play sounds, and closes FMOD in its destructor
6) the application tells the DLL to create a thread, and this thread will call an "update" in our main class, that will also call the sound class update which call the FMOD::update(). NB: EVEN WITHOUT calling FMOD update() at all, it crashes on system->release() BUT at a different location
7) instead of asking the DLL to create an update thread, the application can call an update() function in the DLL that directly calls update of the main class that will call update of the sound class that will call update of FMOD. Usually done from a windows timer in the .exe. In this case, FMOD ALSO CRASHES (no additional thread involved)
8 ) the exe can tell the DLL to close, and then the DLL closes the main class which call the sound class to close which call system->release()

I think it is safe to say there is no thread pbm in this architecture, but you certainly have more experience in the matter.

Obviously, again, cannot you add a simple "if (my_variable !=0) before calling the function of your class? because it looks like it is the issue. I don’t have YOUR source code, but does it makes sense when I read the information I have that I assume there is a realchannel class in your code, with virtual functions? it looks like the vfptr table is pointing to "non valid" memory for the code somewhere.

I’m quite stuck. However, maybe I don’t need to call ->release() at all? question: when the .exe call the .DLL to tell it to close, it delete the instance of our main class, and the DLL unloads and the .exe exits. At this stage, I would assume FMOD DLL also unloads from memory and your destructors properly delete all allocated memory? so if I don’t call ->release() at all, there shouldn’t be any memory anyhow nor locked ressources isn’t it?

Just let me know how the best I could help.

  • You must to post comments
0
0

Thanks John, I’ll check that out.

  • You must to post comments
0
0

you can use fmodexd.dll and fmodexd.pdb, if you rename both to fmodex.dll and fmodex.pdb you can get debug info.
It also outputs logging info to the debug window.

  • You must to post comments
0
0

The best way you could help is to find out what it is you are doing that makes that crash happen. It sounds like you can reproduce it easily, so there is something inbetween the init and release causing it.
Putting some if statement around a realchannel pointer is -not- a solution when 99% of the time it works. You make it sound like it always does this by simply calling init and release after each other, but this is not the case. So what in between causes it? You should be able to comment out your whole application inbetween the init and release until you find the cause.

  • You must to post comments
0
0

Hi,

it is still causing the error with the latest 4.04.31

John

  • You must to post comments
0
0

Apologies for hijacking your thread CptLucky, I didn’t know if it was the same problem initially.

  • You must to post comments
0
0

[quote:3unmbt2x]like the others reporting in this forum, I’ve suffered the error (crash) when calling FMOD::System::release()[/quote:3unmbt2x]

I’m not sure if this will help or confuse the issue, but here goes.

I’ve been working on & off with a demo I’m doing which loads & plays a couple sounds and does some mic recording. Well-behaved, no crashes.

I was compiling it as a stand-alone WIN console app.

I wanted to call the demo from a larger app, so I added __declspec(dllexport) to my classes and made a DLL out of it.

When exercised from the parent app, it works fine – just like it did with the static compile. Except…

It crashes on Sound->release().

And if I comment that out, it crases on EventSystem->release().

I ran to the forum to see what’s up and came across this thread… this seems related.

If I leave ALL my code intact and just compile it stand-alone, it’s fine. But as a DLL it crashes at the release() points.

I’m using 4.03.30.

HTH,
Bill

  • You must to post comments
0
0

I’ve been getting problems when calling release recently too (technically through EventSystem::release, but that calls system::release anyway IIRC). I can get it to crash fairly often with a specific sequence of actions in my code (not really possible to extract an example to send though I’m afraid), although if I do a Sleep(someSmallTime) or such like before the release, it doesn’t crash.

Of course the sleep could be hiding any number of sins, but is it necessary to have a delay between stopping and unloading sounds/events and calling release?

  • You must to post comments
0
0

Brett,

the error is still at the same location, but I have a couple more info to trace! Here is a dump of the debugger. The error is at 00708F8A with the mov eax, dword ptr [esi] with esi in this session beeing 0x02C97640.

[code:ghfjqe3x]
00708F39 call FMOD::ChannelPool::getNumChannels (757CEBh)
00708F3E cmp eax,ebx
00708F40 je FMOD::OutputDSound::update+200h (708F47h)
00708F42 jmp FMOD::OutputDSound::update+278h (708FBFh)
00708F44 mov dword ptr [numchannels],ebx
00708F47 xor edi,edi
00708F49 cmp dword ptr [numchannels],ebx
00708F4C jle FMOD::OutputDSound::update+23Ch (708F83h)
00708F4E mov ecx,dword ptr [esi+3Ch]
00708F51 lea eax,[channelreal]
00708F54 push eax
00708F55 push edi
00708F56 call FMOD::ChannelPool::getChannel (757D5Ch)
00708F5B cmp eax,ebx
00708F5D jne FMOD::OutputDSound::update+278h (708FBFh)
00708F5F mov ecx,dword ptr [channelreal]
00708F62 cmp ecx,ebx
00708F64 je FMOD::OutputDSound::update+272h (708FB9h)
00708F66 cmp dword ptr [numlisteners],1
00708F6A jg FMOD::OutputDSound::update+22Dh (708F74h)
00708F6C test word ptr [ecx+46h],420h
00708F72 je FMOD::OutputDSound::update+236h (708F7Dh)
00708F74 mov eax,dword ptr [ecx]
00708F76 call dword ptr [eax+60h]
00708F79 cmp eax,ebx
00708F7B jne FMOD::OutputDSound::update+278h (708FBFh)
00708F7D inc edi
00708F7E cmp edi,dword ptr [numchannels]
00708F81 jl FMOD::OutputDSound::update+207h (708F4Eh)
00708F83 mov esi,dword ptr [esi+244h]
00708F89 push esi
00708F8A mov eax,dword ptr [esi]
00708F8C call dword ptr [eax+44h]
00708F8F test eax,eax
00708F91 je FMOD::OutputDSound::update+276h (708FBDh)
00708F93 push dword ptr [hr]
00708F96 push offset string "IDirectSoundListener::CommitDefe"... (790ED0h)
00708F9B push offset string "OutputDSound::update" (790F14h)
00708FA0 push 5CDh
00708FA5 push offset string "c:\pc\src\sound\fmod4\win32\src\"... (790B88h)
00708FAA push 1
00708FAC call FMOD::Debug (70ED5Eh)
[/code:ghfjqe3x]

In short, it is in your outputDSound::Update, there is a call to get the number of channels, and then a loop to check each channel and if the channel is "real", then it must do something prior calling IDirectsoundListener::CommitDeferedSettings().

Also interesting, the debuger locals show a "this" points of type FMOD::OutputDSound * const with a value of 0x3F800000 which in fact does not look to be a pointer (it is 1.0f float in IEEE hexa).

Another debugger hint makes me think the issue is with the class "channelreal" wich is has virtual functions, and with a __frptr which cannot be evaluated (so my hinch in my previous post could proove to be the reason of what is happening).

NB: I’m not using 3D sound, just normal sound.

Hope this helps! this is so very well located in the code that I see no reason we can’t solve it once for all!

And the call stack to go to this error is:

FMOD::SystemI::release() Line 3470
FMOD::SystemI::close() Line 5086
FMOD::SystemI::closeEx(unsigned char calledfrominit = 0x00) line 5142
FMOD::SystemI::update() Line 5480
FMOD::OutputDSound::updateCallback(FMOD_OUTPUT_STATE* output=0x003586b0) Line 2441
FMOD::OutputDSound::update() Line 1483 + 0x7 bytes

Hope this helps!

  • You must to post comments
0
0

[quote="billp":3cd47ps2][quote:3cd47ps2]
I’m using 4.03.30.
[/quote:3cd47ps2][/quote:3cd47ps2]

That is an extremely old version so unfortunately that doesnt help at all, it could be any manner of things that were fixed. The current version is 4.04.35

  • You must to post comments
0
0

are you using non blocking loading at all, if so we just fixed a timing related issue there in v33

  • You must to post comments
0
0

If you are certain that you are using only 2D sounds (FMOD_2D) then are you using more than one listener?

  • You must to post comments
0
0

[quote:3vdwupa1]That is an extremely old version so unfortunately that doesnt help at all, it could be any manner of things that were fixed. The current version is 4.04.35[/quote:3vdwupa1]

Sorry… that was a typo… I’m indeed using the current "4.04.30 stable" release.

  • You must to post comments
0
0

Yes, I am using non-blocking loading. I’ll update to v33 and check

  • You must to post comments
0
0

I’m a bit suspicious of cptlucky’s crash because if it was as simple as System::release everyone would get it, and noone else is getting it, so i really need the steps to reproduce that, and for you to make sure its not something in your code corrupting fmod.

If fmod has a pointer of 0x3f800000 then it is possible a corruption from some other place has stomped on it with float data.

The last crash with crouton and a few others was a specific case of fsb files being opened as streams and timing. This is not specific to anything it is just a matter of releasing the system object which everyone is doing.

If it is reproducible then can’t you just start disabling stuff in your code until it goes away until you find the culprit?

  • You must to post comments
0
0

thats still a different branch to what we’re talking about, could you try with the development branch

  • You must to post comments
0
0

Well, I’ve just checked with v33 and it is still happening. NB: I’m not using NON BLOCKING API at all. I’ve tried the tip in this thread in adding a Sleep(1000) before the call to system->release() and this does not change anything.

It is hard to tell what particular sequence of action when opening the API could lead to this, however, the directions I’ve given to locate the code trying to get a value from memory from a pointer to this memory that is null should be easy to catch? It is always crashing at the same code location…

Hope this helps!

  • You must to post comments
0
0

Hi Bret, I’m sure it is something simple. Maybe a set of parameters goes wild in the lib? Neverheless, I’ve removed any call to create sound / create channel, so the application just init the sound library with the code pasted below, and closes it when leaving the application, with a call to update between the two in a thread that just does that: calling FMOD:update()

[code:2ipouz46]
//—————————————————————-

    FMOD_RESULT result;

    //----------------------------------------------------------------
    // create the main system

    result = FMOD::System_Create(&amp;SoundSystem);     // Create the main system object.
    if (result != FMOD_OK)
        throw (result);

    //----------------------------------------------------------------
    // need 32 channels minimum

    result = SoundSystem-&gt;setSoftwareChannels(32);
    if (result != FMOD_OK)
        throw (result);

    //----------------------------------------------------------------
    // setup the software mixer format

    result = SoundSystem-&gt;setSoftwareFormat(48000,FMOD_SOUND_FORMAT_PCM16,2,2,FMOD_DSP_RESAMPLER_LINEAR);
    if (result != FMOD_OK)
        throw (result);

    //----------------------------------------------------------------
    // setup the output speakers with the control panel speaker modes

    int numdrivers;
    result = SoundSystem-&gt;getNumDrivers(&amp;numdrivers);
    if (result != FMOD_OK)
        throw (result);
    if (numdrivers == 0)
        throw (&quot;No Sound Card detected on the system&quot;);

    // assume primary output driver is always at index 0

    FMOD_CAPS           caps;
    FMOD_SPEAKERMODE    speakermode;
    result = SoundSystem-&gt;getDriverCaps(0,&amp;caps,0,0,&amp;speakermode);
    if (result != FMOD_OK)
        throw (result);

    result = SoundSystem-&gt;setSpeakerMode(speakermode);
    if (result != FMOD_OK)
        throw (result);

    //----------------------------------------------------------------
    // ready to start the system

    result = SoundSystem-&gt;init(100, FMOD_INIT_NORMAL, 0);    // Initialize FMOD.
    if (result != FMOD_OK)
        throw (result);

    //----------------------------------------------------------------
    // Create sound Groups

    result = SoundSystem-&gt;getMasterChannelGroup( &amp;SoundGroups[Group_Master]);
    if (result != FMOD_OK)
        throw (result);

[/code:2ipouz46]

And here is below the log file:

[code:2ipouz46]
FMOD: OutputDSound::registerDLL : Detected DIRECTX 9
FMOD: FMOD_Output_DSound_EnumProc : Enumerating "Primary Sound Driver"
FMOD: FMOD_Output_DSound_EnumProc : Enumerating "SoundMAX HD Audio"
FMOD: FMOD_Output_DSound_EnumProc : Enumerating "Bluetooth Audio"
FMOD: FMOD_Output_DSound_EnumProc : Enumerating "Bluetooth High Quality Audio"
FMOD: OutputDSound::getDriverCaps : Register DLL
FMOD: OutputDSound::getDriverCaps : Enumerate Drivers
FMOD: OutputDSound::getDriverCaps : CoInitialize
FMOD: OutputDSound::getDriverCaps : DirectSoundCreate8 : id = 0
FMOD: OutputDSound::getDriverCaps : GetCaps
FMOD: OutputDSound::init : Bad Caps or emulated driver. Reverting back to software
FMOD: OutputDSound::close :
FMOD: OutputDSound::close : Free channel pool 2d
FMOD: OutputDSound::close : Free channel pool 3d
FMOD: OutputDSound::close : Release directsound listener
FMOD: OutputDSound::close : Release directsound object
FMOD: OutputDSound::close : FreeLibrary on dsound3d.dll
FMOD: OutputDSound::close : FreeLibrary on dsound.dll
FMOD: OutputDSound::close : Free driver list
FMOD: OutputDSound::close : done
FMOD: SystemI::init : maxchannels = 100, flags = 00000000, extradriverdata = 00000000
FMOD: SystemI::close :
FMOD: SystemI::close : Shut down streamer and FMOD_NONBLOCKING and FileSystem thread.
FMOD: SystemI::close : Remove all user channel groups.
FMOD: SystemI::close : Remove ‘main’ channel group.
FMOD: SystemI::close : Remove miscllaneous DSP stuff.
FMOD: SystemI::close : done.

FMOD: OutputDSound::init : Register DLL
FMOD: OutputDSound::init : Enumerate Drivers
FMOD: FMOD_Output_DSound_EnumProc : Enumerating "Primary Sound Driver"
FMOD: FMOD_Output_DSound_EnumProc : Enumerating "SoundMAX HD Audio"
FMOD: FMOD_Output_DSound_EnumProc : Enumerating "Bluetooth Audio"
FMOD: FMOD_Output_DSound_EnumProc : Enumerating "Bluetooth High Quality Audio"
FMOD: OutputDSound::init : DirectSoundCreate8 : mSelectedDriver = -1
FMOD: OutputDSound::init : SetCooperativeLevel
FMOD: OutputDSound::init : GetCaps
FMOD: OutputDSound::init : Bad Caps or emulated driver. Reverting back to software
FMOD: OutputDSound::init : Create Primary Buffer
FMOD: OutputDSound::init : Set Primary Buffer Format
FMOD: OutputDSound::init : Getting Listener Interface
FMOD: OutputDSound::init : Done
FMOD: SystemI::init : Set up software engine
FMOD: OutputDSound::createSample : length 4096, channels 2, format 2, mode 0000002a
FMOD: OutputDSound::createSample : done
FMOD: Thread::initThread : Initializing FMOD mixer thread. priority 3
FMOD: Thread::initThread : – Stacksize 32768. Stack pointer 00000000 : usesemaphore = 0 : sleeptime = 10
FMOD: Thread::initThread : done.
FMOD: Thread::callback : * FMOD mixer thread started
FMOD: SystemI::init : Set up emulated output
FMOD: SystemI::init : create the channel pool
FMOD: SystemI::init : Set up streamer
FMOD: Thread::initThread : Initializing FMOD stream thread. priority 2
FMOD: Thread::initThread : – Stacksize 32768. Stack pointer 00000000 : usesemaphore = 0 : sleeptime = 10
FMOD: Thread::callback : * FMOD stream thread started
FMOD: Thread::initThread : done.
FMOD: SystemI::init : done

FMOD: SystemI::close :
FMOD: SystemI::recordStop :
FMOD: SystemI::recordStop : done
FMOD: SystemI::close : Stop all sounds
[/code:2ipouz46]

  • You must to post comments
Showing 1 - 20 of 30 results
Your Answer

Please first to submit.