Gekkio/mooneye-gb

Mooneye crashes when playing Pokemon blue with accelerator on

alexwennerberg opened this issue · 2 comments

Reproduction:

Using a standard Gameboy BootRom, load Pokemon blue. Hold shift (turbo mode) and select "New game". Continue to hold shift while professor oak is talking, and the emulator panics with this stack trace:

16:25:30 �[34m[ INFO] �[m�Starting Mooneye GB v0.2.0-pre
16:25:30 �[36m[DEBUG] �[m�(1) mooneye_gb::config::bootrom: Scanning /home/alex/.local/share/mooneye-gb/bootroms/dmg_boot.bin for a boot ROM
16:25:30 �[34m[ INFO] �[m�Using DMG (Game Boy) boot ROM from /home/alex/.local/share/mooneye-gb/bootroms/dmg_boot.bin
16:25:30 �[36m[DEBUG] �[m�(1) gilrs::gamepad: Loaded 276 mappings.
16:25:30 �[34m[ INFO] �[m�Guessed window DPI factor: 1
16:25:30 �[36m[DEBUG] �[m�(1) winit::platform::platform::x11::window: Calculated physical dimensions: 640x576
16:25:30 �[34m[ INFO] �[m�Initialized renderer with OpenGL 4.5
thread '<unnamed>' panicked at 'Undefined opcode 228', core/src/cpu/execute.rs:736:5
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:77
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:61
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1028
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1412
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:65
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:50
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:188
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:205
  10: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:464
  11: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:373
  12: std::panicking::begin_panic_fmt
             at src/libstd/panicking.rs:328
  13: mooneye_gb::cpu::execute::<impl mooneye_gb::cpu::Cpu>::undefined
  14: mooneye_gb::cpu::decode::<impl mooneye_gb::cpu::Cpu>::decode_exec_fetch
  15: mooneye_gb::machine::Machine::emulate
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
16:25:34 �[31m[ERROR] �[m�"SendError(..)"

stack backtrace:
   0: failure::backtrace::internal::InternalBacktrace::new
   1: failure::backtrace::Backtrace::new
   2: mooneye_gb::frontend::emu_thread::EmuThreadHandle::stop
   3: mooneye_gb::frontend::SdlFrontend::main
   4: mooneye_gb::main
   5: std::rt::lang_start::{{closure}}
   6: std::rt::lang_start_internal::{{closure}}
             at src/libstd/rt.rs:48
      std::panicking::try::do_call
             at src/libstd/panicking.rs:287
   7: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:78
   8: std::panicking::try
             at src/libstd/panicking.rs:265
      std::panic::catch_unwind
             at src/libstd/panic.rs:396
      std::rt::lang_start_internal
             at src/libstd/rt.rs:47
   9: main
  10: __libc_start_main
  11: _start

Environment:

mooneye-gb 3f79eef
debian buster
Rustc 1.40.0

I did some more work debugging this. Here are my notes:

  1. Still present on 0512e69 using Rustc 1.41
  2. Not present on a3fb4a2 using Rustc 1.26 (I was playing around with this in 2018 and I just verified that it still works on that build)
  3. Still happens with the accelerator off if I push buttons at the right time. Unable to reproduce consistently, how long I press down a button and when I press it down seem to affect it, but it happens at different points during prof Oak's open monologue. I see a variety of different errors, including various corrupted screens of corrupted data, or the ROM crashing.

I can use git bisect to try and isolate the commit where the issue arises if that will help!

OK -- I used git bisect with Rustc 1.33 and isolated the issue as being introduced in this commit: 81f21cf

Hope that helps!