The call stack is all in closed source FMOD code, and since I don’t have a commercial license I don’t have the debug symbols for it. My revision.txt file says this is FMOD version 1.09.04 from 10/04/17 build 86084. The system’s getVersion() also agrees.
I can’t read disassembly, so I couldn’t say anything useful about it.
But here’s an image that shows pretty much everything:
The output in the box is also useless as I said I don’t get any when it crashes. That output that’s there is from when the sound is opened. It doesn’t matter matter if I use createSound or createStream, same result. You can see my diagnostic session is at 48 seconds as I described.
I can try out the playstream example I suppose, but I don’t expect any difference.
I tried the play stream example and I got the crash at the same exact time. Though I noticed something odd. In the console it showed an absurdly long time that doesn’t make any sense as you can see here:
So it simply cannot be my code. This has to be some bug with FMOD or there’s an external source I am unaware of.
Thanks i’ve managed to reproduce it, problem was before, I was using 1.08. It looks like a refactor has caused this issue to sneak into 1.09, so my recommendation would be to use 1.08 for now. 1.09 is nearing release though, in about a week there will be an update and i’ve included a patch to fix the issue for .s3m files.
Thank you very much! I was just about to comment about doing the same thing using FMOD under MinGW with CodeLite with C API. I got the same exact result. Glad to know that it will be fixed. Looking forward to it!
Also using MinGW with the C API gave me a legible stack trace probably due to the lib being built with symbols. Not sure if that’s intended, but it might help somebody else out.