Hi I would also like to request the debug symbols for FMOD for Unity 2.02.07 for Windows please.
Please let me know if you have any trouble accessing them.
Thanks for sending the debug symbols. Unfortunately our programmers are having difficulty loading these symbols to debug a user reported crash dump in this bug report. Here’s the information we have. Are you able to inspect this dmp with your internal symbol server?
- Unhandled exception at 0x00007FFC2D2500C8 (fmodstudio.dll) in SimDLL_CRASH_release_568201_20230831-02_58.19.dmp: 0xC0000005: Access violation reading location 0x000000A882D80048.
I’m so sorry for the confusion. I misread your previous message and supplied the wrong symbols! The symbols I supplied were for FMOD Engine rather than FMOD for Unity. I have uploaded the correct symbol zip to your user profile, hopefully this one will work better for your engineers.
I will also ask our support engineers to take a look at your bug report and attached dump and see if they can provide any insight into the issue.
It worked this time!! Thanks for your help.
I have gone through your crash dump and can see the crash is occurring in our AVX2 optimized Vorbis decoder.
The strange thing I’m seeing at the site of this crash is that we are using a certain memory block that is only supposed to be used when AVX2 is unavailable. From the DxDiag, AVX2 should be available on the user’s CPU, so it is not clear to me why we are using this memory block.
In any case, this memory block isn’t explicitly aligned, which I am guessing is what is causing the crash inside the SIMD call. We could probably prevent this crash from happening by aligning this memory block, but it is still strange that we would need to do that at all. I have passed this onto the Dev team to verify my findings and investigate further.
In the meantime, you could work around this issue by building banks with FADPCM instead of Vorbis.
I’ve looked at your crash dump and traced the crash back to a faulty load instruction. The data in question is a lookup table compiled into the application and I’ve verified it is correct by inspecting through the dump file. However, I can also see a copy of the data held in the registers is very slightly wrong, one of the data elements is off by a single bit. This single bit of inaccuracy has caused an out-of-bounds lookup causing the crash and since there are no intervening instructions I have to suspect faulty hardware.
Do you have reports from other users with a similar crash call stack? I suspect the issue might be limited to this one user.
Thank you for investigating. This is the only report we have of this bug, it could be specific to this users setup. We have followed up with them to see if AVX is disabled in their bios.
That user’s game started working and here is the AVX info they provided just in case it might be useful. Thanks for investigaing this again!
Thanks for the update, please let us know if more users experience this issue.