retroarch crash right after starting a normal sega cd or sega cd 32x game with picodrive. normal 32x games are working without problem.
gabberhead opened this issue · 17 comments
i posted the problem also on the retroarch github site libretro/RetroArch#13129 . i will copy and paste a part of it here, because it is a core issue, not a retroarch issue.
retroarch crash right after starting a normal sega cd or sega cd 32x game. normal 32x games are working without problem. and the normal segacd games are working with genesis plus gx also without problems. i have 2 us bioses with 2 different md5 hashes. both hases are identical to the ones which are listet on the libretro site. jp and eu have the same md5 hashes for genesis plus gx and picodrive. only the us bioses are different for picodrive and genesis gx plus. but with both its not working.
Expected behavior.
somebody answered to my post. this is a part of it:
But I'm super confused about this issue: in my backups I have a version of c567d74 which works perfectly fine with CD games (if anyone wants to try: https://github.com/libretro/RetroArch/files/7359667/picodrive_libretro.zip), but if I build that exact same commit myself it crashes too now... I tried to bisect but now even building a commit from January (f821bb7) crashes oO
And the crash log (Windows 10): https://github.com/libretro/RetroArch/files/7359635/crash-211017-120306.log
Well here is something to try be sure to keep a backup of the file if it is the cause its helped go rename or delete in this case i would rename in case it is causing the issue.
the file you want is in retroarch/config/PicoDrive/PicoDrive.opt im on linux its working fine here fwiw
i deleted the file and tried it. the problem is the same.
I checked it works with Retroarch under OSX and Linux. I suspect it's due to Windows using this strange LLP64 ABI model (AFAIK the only OS that's doing this), but since I don't have any Windows systems at hand I cannot actually help in debugging this :-/
but since I don't have any Windows systems at hand I cannot actually help in debugging this :-/
Pretty noob at debugging so idk if it helps, this is what I get when using gdb under MinGW:
Thread 1 received signal SIGSEGV, Segmentation fault.
0x00007ffb550300d1 in fm68k_emulate (ctx=0x7ffb551bcfc0 <PicoCpuFM68k>,
cycles=482, reason=fm68k_reason_emulate) at cpu/fame/famec.c:867
867 NEXT
(gdb) bt full
#0 0x00007ffb550300d1 in fm68k_emulate (ctx=0x7ffb551bcfc0 <PicoCpuFM68k>,
cycles=482, reason=fm68k_reason_emulate) at cpu/fame/famec.c:867
Opcode = 636
cycles_needed = 0
PC = 0x551a8a48
BasePC = 18446744070842387776
flag_C = 2101248
flag_V = 525312
flag_NotZ = 4
flag_N = 131328
flag_X = 131328
#1 0x00007ffb55001771 in SekRunM68kOnce () at pico/cd/mcd.c:109
cyc_do = 482
#2 0x00007ffb55001f62 in pcd_run_cpus (m68k_cycles=488) at pico/cd/mcd.c:363
No locals.
#3 0x00007ffb550023fd in PicoFrameHints () at pico/cd/../pico_cmn.c:151
pv = 0x7ffb551987a0 <Pico>
lines = 8
y = 177
lines_vis = 245
skip = 0
vcnt_wrap = 0
vcnt_adj = 2
cycles = 3437228688
hint = 0
#4 0x00007ffb55002bf5 in PicoFrameMCD () at pico/cd/mcd.c:405
No locals.
#5 0x00007ffb54fddcd7 in PicoFrame () at pico/pico.c:271
No locals.
#6 0x00007ffb54f856fc in retro_run () at platform/libretro/libretro.c:2059
updated = false
pad = 2
i = 12
buff = 0x24a78290350
#7 0x00007ff6947aef8a in core_run () at retroarch.c:21298
runloop_st = 0x7ff6957b82e0 <runloop_state>
current_core = 0x7ff6957b8328 <runloop_state+72>
core_poll_type_override = POLL_TYPE_OVERRIDE_DONTCARE
new_poll_type = 2
early_polling = false
late_polling = true
netplay_preframe = true
#8 0x00007ff6947adbe7 in runloop_iterate () at retroarch.c:20617
run_ahead_enabled = false
run_ahead_secondary_instance = true
want_runahead = false
run_ahead_num_frames = 1
run_ahead_hide_warnings = false
i = 5
dpad_mode = {ANALOG_DPAD_NONE, ANALOG_DPAD_NONE, ANALOG_DPAD_NONE,
ANALOG_DPAD_NONE, ANALOG_DPAD_NONE, 586, 2014339536, 586,
198474880, 586, 3361294257, 32763, ANALOG_DPAD_NONE,
ANALOG_DPAD_NONE, 2016280576, 586}
p_rarch = 0x7ff695796ce0 <rarch_st>
input_st = 0x7ff6957db5c0 <input_driver_st>
audio_st = 0x7ff6957d2740 <audio_driver_st>
video_st = 0x7ff6958019c0 <video_driver_st>
settings = 0x24a78249090
runloop_st = 0x7ff6957b82e0 <runloop_state>
video_frame_delay = 0
vrr_runloop_enable = false
max_users = 5
current_time = 679907219
menu_pause_libretro = true
core_paused = false
slowmotion_ratio = 3
cheevos_enable = false
audio_sync = true
discord_st = 0x7ff6957acdf8 <rarch_st+90392>
#9 0x00007ff6947936fe in rarch_main (argc=1, argv=0x24a782edb10, data=0x0)
at retroarch.c:8987
ret = 0
app_exit = false
p_rarch = 0x7ff695796ce0 <rarch_st>
runloop_st = 0x7ff6957b82e0 <runloop_state>
video_st = 0x7ff6958019c0 <video_driver_st>
#10 0x00007ff694981ddd in SDL_main (argc=1, argv=0x24a782edb10)
at ui/drivers/ui_qt.cpp:4315
No locals.
#11 0x00007ff694ed5f5a in main_getcmdline ()
No symbol table info available.
#12 0x00007ff6947813c1 in __tmainCRTStartup ()
at C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:321
lock_free = <optimized out>
fiberid = <optimized out>
nested = <optimized out>
lpszCommandLine = <optimized out>
StartupInfo = {cb = 104, lpReserved = 0x24a7810ea30 "",
lpDesktop = 0x24a78111fa0 "Winsta0\\Default",
lpTitle = 0x24a78111c50 "G:\\msys64\\home\\B-S\\build\\retroarch_debug.exe", dwX = 0, dwY = 0, dwXSize = 0, dwYSize = 0, dwXCountChars = 0,
dwYCountChars = 0, dwFillAttribute = 0, dwFlags = 0,
wShowWindow = 0, cbReserved2 = 0, lpReserved2 = 0x0,
hStdInput = 0xffffffffffffffff, hStdOutput = 0xffffffffffffffff,
hStdError = 0xffffffffffffffff}
inDoubleQuote = <optimized out>
#13 0x00007ff6947814d6 in WinMainCRTStartup ()
at C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:176
ret = 255
edit: Also I've seen someone posting "info frame" and "info reg" on a PPSSPP issue a while ago, I have no idea what this is but I guess it might help? Maybe not, but just in case:
(gdb) info frame
Stack level 0, frame at 0x63e23ff1b0:
rip = 0x7ffb54aa00d1 in fm68k_emulate (cpu/fame/famec.c:867);
saved rip = 0x7ffb54a71771
called by frame at 0x63e23ff1f0
source language c.
Arglist at 0x63e23f94c0, args: ctx=0x7ffb54c2cfc0 <PicoCpuFM68k>,
cycles=448, reason=fm68k_reason_emulate
Locals at 0x63e23f94c0, Previous frame's sp is 0x63e23ff1b0
Saved registers:
rbp at 0x63e23ff1a0, rip at 0x63e23ff1a8
(gdb) info reg
rax 0x54c18a46 1421969990
rbx 0x0 0
rcx 0x7ffb54c2cfc0 140717435572160
rdx 0x54c18a48 1421969992
rsi 0x7ff69564770e 140697045071630
rdi 0x7ff695647705 140697045071621
rbp 0x63e23f9540 0x63e23f9540
rsp 0x63e23f94c0 0x63e23f94c0
r8 0x0 0
r9 0x2010 8208
r10 0x7ff6957dbb30 140697046727472
r11 0x0 0
r12 0x1c10e204e00 1928677314048
r13 0x1c10e3cdb10 1928679185168
r14 0x0 0
r15 0x0 0
rip 0x7ffb54aa00d1 0x7ffb54aa00d1 <fm68k_emulate+1159>
eflags 0x10246 [ PF ZF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x53 83
gs 0x2b 43
I see that the PC ptr has a value of 0x551a8a48 and BasePC is 0xFFFFFFFF551A8D40. The upper 32 bits are in one case all 0 and in the other case all 1.
That look very much like a pointer conversion problem somewhere. But finding that without single stepping and observing those 2 values might be very difficult.
Are standard Megadrive games working?
Yeah, no issue with regular games, only CD ones.
hmm. No immediate idea ATM.
I wonder if it could be related to that PX68k core issue: libretro/px68k-libretro#150 🤔
Maybe something broke with a Windows update or something, this is super weird...
Hmm, it's a different 68k interpreter, so this might or might not be unrelated.
Does anybody know if I can compile and run retroarch under wine in osx or linux?
Following this thread, and holding onto the older core for now :)
yes you can run retroarch under wine it does work.
Seems to be an issue with the buildbot? libretro/px68k-libretro#150 (comment)
Same commit: crashes with .dll from the online updater, no crash with the .dll from RA 1.9.11 cores bundle.
Same goes for PicoDrive and NP2Kai, cores crash with the versions from the online updater but they run fine from the 1.9.11 bundle.
edit: Absolutely no idea what that means, but a RA dev compared working and broken .dll for PX68k, I did the same thing for PicoDrive and got the same results:
Broken core has some "DLL Flags" that the working DLL doesn't have. Could be unrelated of course, idk.
edit2: Yeah seems related, I've added -Wl,--disable-dynamicbase,--disable-high-entropy-va,--default-image-base-low as linker flags (https://www.msys2.org/news/#2021-01-31-aslr-enabled-by-default) and the core now loads properly.
If anyone has (or can suggest) a compile-and-test scenario with the toolchain used by the buildbot, running under either linux or OSX, I'd appreciate some info.
I was loosely following the procedure described on libretro.com for windows building and did this:
sudo apt-get install mingw-w64 wine64
make CC=x86_64-w64-mingw32-gcc -f Makefile.libretro clean all platform=windows
wine64 retroarch.exe -v -L picodrive-libretro.dll <...>.cue
That indeed runs me a self-built picodrive dll inside a windows retroarch on wine.
However, with this setup there's absolutely no problem, the thing runs fine. Any ideas anyone?
Maybe a different compiler version? @bslenul which compiler version are you using?
Not sure if that's what you're asking but when typing gcc --version I get that:
gcc.exe (Rev2, Built by MSYS2 project) 10.3.0
And can you reproduce the crash with the .dll from the buildbot with Wine?