BizHawk is a multi-system emulator written in C#. BizHawk provides nice features for casual gamers such as full screen, and joypad support in addition to full rerecording and debugging tools for all system cores.
Affects at least version 2.4 and latest master commit 0075693ec79793a9751edadc86927fbcb9586ffe
This issue is directly related to issue #1787
Playing and dumping a movie that has a different input configuration than the current configuration at the time of playing the movie causes Octoshock to crash. For example, if the current configuration is for a Dualshock controller for P1 and a Dualshock controller for P2, loading and dumping a movie with a Dualshock controller for P1, but no controller for P2 will cause the crash. Sometimes no AVI dumping is needed, and the core will crash with just the movie, but this behavior is inconsistent.
Both NES and both SNES cores have also been tested for this behavior, and none of them exhibit it. Only the Ocotoshock core thus far.
For reproducing the bug, you need a movie file that is configured to use a Dualshock controller for P1 w/ memcard, and no controller or memcard for P2. My file started from a save state, and was a tasproj movie. Not sure if those are relevant.
Reproduction steps are very finicky, follow carefully:
Launch BizHawk
Load PSX game
PSX > Controller / Memcard Configuration
Change both players to use Dualshock controllers w/ memcards. If this is how it is already set up, click stuff to get the "reboot required" message to appear post config.
Reboot Octoshock core
Pause the emulator
File > Movie > Play Movie
Select the movie with different input configuration
File > AVI/WAV > Record (or configure)
Set up dump (avi-lossless used for testing)
Unpause emulator
Access violation / crash to desktop
The crash is occurring in the UpdateInput() function in psx.cpp:
It appears that the ports memory is getting clobbered or is otherwise corrupt at the time the movie is resumed. It will crash when trying to dereference the no-controller device at index 1.
A possibly relevant observation is that when BizHawk successfully loads and starts dumping movies, upon closing and restarting the emulator, the input settings will have been modified to match the previous movie. When the AV crash occurs however, BizHawk will frequently start up with the input configuration that causes the crash.
I can furnish all of the files necessary to reproduce this bug if requested.
Affects at least version 2.4 and latest master commit 0075693ec79793a9751edadc86927fbcb9586ffe
This issue is directly related to issue #1787
Playing and dumping a movie that has a different input configuration than the current configuration at the time of playing the movie causes Octoshock to crash. For example, if the current configuration is for a Dualshock controller for P1 and a Dualshock controller for P2, loading and dumping a movie with a Dualshock controller for P1, but no controller for P2 will cause the crash. Sometimes no AVI dumping is needed, and the core will crash with just the movie, but this behavior is inconsistent.
Both NES and both SNES cores have also been tested for this behavior, and none of them exhibit it. Only the Ocotoshock core thus far.
For reproducing the bug, you need a movie file that is configured to use a Dualshock controller for P1 w/ memcard, and no controller or memcard for P2. My file started from a save state, and was a tasproj movie. Not sure if those are relevant.
Reproduction steps are very finicky, follow carefully:
The crash is occurring in the
UpdateInput()
function in psx.cpp: It appears that the ports memory is getting clobbered or is otherwise corrupt at the time the movie is resumed. It will crash when trying to dereference the no-controller device at index 1.A possibly relevant observation is that when BizHawk successfully loads and starts dumping movies, upon closing and restarting the emulator, the input settings will have been modified to match the previous movie. When the AV crash occurs however, BizHawk will frequently start up with the input configuration that causes the crash.
I can furnish all of the files necessary to reproduce this bug if requested.