[Bug 46918] New: Call of Duty: Black Ops crashes when using FAudio
https://bugs.winehq.org/show_bug.cgi?id=46918 Bug ID: 46918 Summary: Call of Duty: Black Ops crashes when using FAudio Product: Wine Version: 4.4 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: xaudio2 Assignee: wine-bugs(a)winehq.org Reporter: andrey.goosev(a)gmail.com Distribution: --- Created attachment 64007 --> https://bugs.winehq.org/attachment.cgi?id=64007 log Game crashes right after clicking LMB to skip intro movie. err:seh:raise_exception Unhandled exception code c0000005 flags 0 addr 0x509c26 The next scheme helps with entering the main menu: 1. Set xaudio2_7 to 'disabled' 2. Launch game -> Settings -> Audio 3. Change 'Sound Occlusion' option to 'Off' 4. Quit from game 5. Set xaudio2_7 to 'builtin' but now crash happens when start a campaign. wine-4.4-232-gc7f323107b -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46918 pattietreutel <katyaberezyaka(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katyaberezyaka(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46918 Ethan Lee <flibitijibibo(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |flibitijibibo(a)gmail.com --- Comment #1 from Ethan Lee <flibitijibibo(a)gmail.com> --- More XAPOs... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46918 --- Comment #2 from Ethan Lee <flibitijibibo(a)gmail.com> --- This one's really strange - there are lots of submix XAPOs that are fine, with the crash happening immediately after the first time a source XAPO's parameters are updated. All the effects are custom implementations made by Treyarch, so no symbols to be found here. The part that's weird is the Source DSP (which is what it's called), which has a SetParameters implementation that behaves roughly like this: // ParameterByteSize == 64 void SetParameters(void* pParameters, uint32_t ParameterByteSize) { float* src = (float*) pParameters; float* dst = (float*) this->m_pParameterBlocks + (0 through 2); for (int i = 0; i < 12; i += 1) { dst[i + 1] = src[i + 4]; } } This... doesn't make a lot of sense. The typical case is to simply copy pParameters to m_pParameterBlocks with the intended ParameterByteSize, and this just avoids that entirely. I feel like I'm either misinterpreting the assembly or missing some huge detail in how this is meant to work, because these values are what appear to derail the program (IXAPO::Process starts corrupting things). Avoiding the SetParameters for this one XAPO allows everything to function correctly. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46918 --- Comment #3 from Ethan Lee <flibitijibibo(a)gmail.com> --- Cool, so I was actually reading the asm correctly and my debugger was just having a fun day. It actually does for (int i = 0; i < 16; i += 1) { dst[i] = src[i] } Which makes more sense than whatever my debugger was doing yesterday, but still doesn't explain why there are 48 bytes just doing nothing in the effect. At least all the values are 0 I guess...? Until we get into Process and then it writes into the parameter buffer some time before crashing on the main thread. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46918 --- Comment #4 from Ethan Lee <flibitijibibo(a)gmail.com> --- I am very smart. 16 floats is 64 bytes. I swear I passed a math class once! So SetParameters is fine on the surface, but the fact that us calling it causes a crash is still worrying. Interestingly the data that gets dumped into the XAPO's internal parameter buffer is always the same, which means it's either intentional or there's a consistently-reproducible overwrite. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46918 --- Comment #5 from Dmitry Timoshkov <dmitry(a)baikal.ru> --- (In reply to Ethan Lee from comment #4)
I am very smart. 16 floats is 64 bytes. I swear I passed a math class once!
Are you confusing floats with doubles? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46918 --- Comment #6 from Ethan Lee <flibitijibibo(a)gmail.com> --- Worse, I had the sense to convert to float when I was reading out the bytes, but still expected 64 values... so I was confusing bytes with floats. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46918 --- Comment #7 from Ethan Lee <flibitijibibo(a)gmail.com> --- More on the "why did I let myself open the disassembly tab" saga: I stepped through the Source DSP's Process function and it seems the reason for crashing may be an infinite loop. Consider this function... void Blorp(float4* x, float4* y) { while (x != y) { *x = *y; // Just making something up... x++; } } For whatever reason it's giving the equivalent of Blorp(0x430, 0x420) when SetParameters is called. This causes infinite overwriting, resulting in corruption in other parts of the engine, which is why the crash doesn't necessarily happen on the audio thread but does always stop when the audio thread is in IXAPO_Process. When we skip SetParameters it doesn't even go to the routine in question, so unfortunately it's hard to say if there's a corrupted variable without just My First Fuzzing the thing. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46918 Paul Gofman <gofmanp(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gofmanp(a)gmail.com --- Comment #8 from Paul Gofman <gofmanp(a)gmail.com> --- Created attachment 66683 --> https://bugs.winehq.org/attachment.cgi?id=66683 PoC hack for FAudio I've tested the game. Unlike somewhat similar looking problem in Bug #46725 where the game's xapos were ignoring buffer sizes provided in _LockForProcess, this game is mindful about these parameters. But unfortunately it gets zero MaxFrameCount for the problematic xapo. Then it overwrites some data in xapos's _Process function and things go weird. This happens probably because the voice's number of samples is not initialized at voice creation, this is done later. Application sets effect chain before number of samples is initialized for the voice. The attached proof of concept hack is fixing the issue for me. Please note that the correct value of 480 (for audio frequency present in game) is important, if I set 512 there the game crashes as well, so it is sort of dependent on Bug #46725. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46918 --- Comment #9 from Ethan Lee <flibitijibibo(a)gmail.com> --- This seems like a pretty good indicator that SetOutputVoices and SetEffectChain are even more tightly-coupled together than we already knew. What most likely needs to happen is a merge of the all the code in those functions into a single FAudio_INTERNAL_ValidateVoiceOutput so that all the validation happens together, meaning we always have enough information for all the little details in the voices (in this case, whether or not we can lock the XAPO for processing). The good news is that the mix thread is already smart enough to not do any processing when there’s no output, we just need to be smart enough to not lock the effects until we have those output voices. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46918 --- Comment #10 from Paul Gofman <gofmanp(a)gmail.com> --- Yes, can’t it be that Windows just calls _LockForProcess only when the voice chain is initialized and about to start? Why would they make a separate function otherwise? If that is the case then there is the room for other problems in apps which get that called at the wrong moment. But this probably can’t be guessed without testing on Windows. IIRC when I was running my test for the previous bug with additional logging Windows did not call _Lock on adding effect, but that is something to be verified. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46918 --- Comment #11 from Ethan Lee <flibitijibibo(a)gmail.com> --- Played around with the official XAPO example projects and discovered some interesting rules from some debug assertion failures. I also discovered that SetOutputVoices was a complete mess and was doing things in just about the worst order possible. I've made a new commit to address all of these things: https://github.com/FNA-XNA/FAudio/commit/f6df13f507261268debef92846f68b10792... So now it should have a valid MaxFrameCount when applying an effect chain on a voice with no sends. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46918 --- Comment #12 from Paul Gofman <gofmanp(a)gmail.com> --- (In reply to Ethan Lee from comment #11)
Played around with the official XAPO example projects and discovered some interesting rules from some debug assertion failures. I also discovered that SetOutputVoices was a complete mess and was doing things in just about the worst order possible. I've made a new commit to address all of these things:
https://github.com/FNA-XNA/FAudio/commit/ f6df13f507261268debef92846f68b107929e7bb
So now it should have a valid MaxFrameCount when applying an effect chain on a voice with no sends.
Will all go right if the application calls SetEffectChain on source or submix voice before setting output voice? And if Windows indeed calls LockForProcess later (not sure if it is the case) should not FAudio do the same? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46918 --- Comment #13 from Ethan Lee <flibitijibibo(a)gmail.com> --- As long as the output sample rates match when calling SetOutputVoices after SetEffectChain it should be okay, otherwise that’s an error even in XAudio2. I was also able to verify that LockForProcess is called during SetEffectChain (or voice creation, if a chain is passed). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46918 Andrey Gusev <andrey.goosev(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |NOTOURBUG Status|NEW |RESOLVED --- Comment #14 from Andrey Gusev <andrey.goosev(a)gmail.com> --- Marking fixed. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla