Hi

Im using FMOD for sound and there is now a problem (i think it's a general problem and not specific to FMOD itself though).

Debug breaks with first-chance exception (followed by an unhaldled exception). It reads "eccess violation reading location...." I know the error is that i try to do operations (change frequency/volume) on a null-sound (an null pointer, not a valid loaded sample)

I guess I cannot debug it since the symbols are not loaded? Using visual studio C++.

It breaks into a tab "No symbols loaded" with the title "fmod.pdb not included". I don't have that file and don't think i need it since i dont want to debug the FMOD library. Preferably i want to be able to see in the call stack where in my own code i got the crash.

Possible?

Thanks
Erik

You should be able to set break points in your own code, even if you don't have fmod.pdb - assuming your project is set up to generate debug information.

You'll have to try and catch this crash in your own code - it sounds the code is running through a couple of FMOD function calls before it hits something that actually makes it crash (accessing an invalid memory address)... which is why you're not seeing anything in the callstack.

Try putting in nullptr checks in your function that's trying to modify the volume, and assert if your sound object isn't valid.

When you get crashes that you don't have the source code for, usually one of the following is true:

• The call stack will have one of your functions which called the code that you don't have source for.  Double click on your function in the stack to go "back" to that function, then examine anything there which you have debug information for.
• The crashed code might be on a different thread and doesn't have any of your code on the callstack.  You might get some useful information from the Debug -> Windows -> Parallel Stacks window, depending on what kind of thread synchronization is being used.

" I know the error is that i try to do operations (change frequency/volume) on a null-sound (an null pointer, not a valid loaded sample)"

So don't do that

13 hours ago, Nypyren said:

So don't do that

Yeah i know But i wanted to see how i can more easily find the error.

In the call stack it just points out the dll file so i cannot "go up" in the call stack and find the place in my code which caused the crash. So the best solution seams to be to check for null-pointers in my own code right? I just do:

if (soundPointer == 0)
  handleProblem();

Is this what you mean? What would "assert" mean in this case?

These days you're probably better off using nullptr instead of 0... but essentially, yes  

Asserts allow a programmer to raise an error if continued execution of the code will result in a crash.

http://www.cplusplus.com/reference/cassert/assert/

In your case you have a couple of options. If you want the code to continue executing and just spit out an error message, at the start of your function use an if statement (as in your last post) to check if your soundPointer is null and output an error (then return from the function).

If your soundPointer being null is going to a cause catastrophic failure in your game, you can use an assert.

There's a lot of debate about how and when asserts should be used, but I don't want to get all philosophical