https://bugs.winehq.org/show_bug.cgi?id=43567
--- Comment #3 from Jan Havran havran.jan@email.cz --- Created attachment 63120 --> https://bugs.winehq.org/attachment.cgi?id=63120 WINEDEBUG=+tid,+seh,+timestamp,+snoop
I was digging in assembler and tried to trace calls until the crash. I chose mission "Swamped" for reproducing the bug, because it is one of few missions which do not crash because of bug #9337, and because the radio call in this mission is not raised by game event, but by the user.
At the beginning of the mission simply follow the pointman. When he stops for the first time (stops made just to wait for the team are not counted), he see VietCong guard at the water. Continue until he stops for second time - this time he sees hut in the water. Now it is good time to save the game for better reproducibility in the future.
From now, when you talk to the pointman (the USE button), the radio sound is
played ant the game crashes.
I noticed that there is a function INP_UC_GetStatusJustPressed (at address 0x101375E0) in log called periodically, which has most of the time return value 0: logs.?INP_UC_GetStatusJustPressed@@YAKPAUs_INP_UniControl@@@Z() retval=00000000 but sometimes (rarely) 1: logs.?INP_UC_GetStatusJustPressed@@YAKPAUs_INP_UniControl@@@Z() retval=00000001 The experiments showed up that value 1 is returned only when the user press the button (does not matter if it will raise any action or not).
The attached log begins from this part - player is in the situation described above and talks to pointman.
A quick look into the log shows us that this causes the call of SCR_ExecScript (logs.dll) and SNDS_GetSpeechInfo (logs.dll), which does a lot of ogg stuff (probably playing the radio sound).