search

hrydgard / ppsspp

A PSP emulator for Android, Windows, Mac and Linux, written in C++. Want to contribute? Join us on Discord at https://discord.gg/5NJB6dD or just send pull requests / issues. For discussion use the forums at forums.ppsspp.org.
https://www.ppsspp.org
Other
11.17k stars 2.17k forks source link

RetroArch crashes when loading PPSSPP savestates #11429

Closed ghost closed 3 years ago

ghost commented 6 years ago

RetroArch crashes whenever I load a PPSSPP savestate. The loading state message shows up, stops at 50-70%, and then it crashes without an error message. Happens in all games I tested. Closer to not crashing I've come is Megaman Maverick Hunter, where instead of crashing loading a state shows the background layer and hangs the game.

I'm using RetroArch 1.7.4, PPSSPP core 9c9432e, Win 10 17134.286, and OpenGL render.

RaulMarq commented 5 years ago

Having the same issue here on the latest version of RetroArch as of today, the games I'm trying to load save states on are Fate/EXTRA and Final Fantasy Tactics War of the Lions.

unknownbrackets commented 5 years ago

I assume this doesn't happen in PPSSPP itself, right? I don't know a lot about how libretro manages save states, but I do know it bypasses PPSSPP's management and has functions to access PPSSPP's RAM directly (but not scratchpad SRAM and VRAM.) It might just not be creating a proper save state.

-[Unknown]

RaulMarq commented 5 years ago

I was able to create/load save states just fine on PPSSPP last year when I played Fate/EXTRA, yes. I can also, in fact, save/load in-game saves just fine on RetroArch and creating save states doesn't show any errors on the screen, it's just when trying to load said save states that I get an instant CTD.

ghost commented 5 years ago 
      I was able to create/load save states just fine on PPSSPP last year when I played Fate/EXTRA, yes. I can also, in fact, save/load in-game saves just fine on RetroArch and creating save states doesn't show any errors on the screen, it's just when trying to load said save states that I get an instant CTD.

Same thing happens to me; standalone works fine, but loading a state in the RetroArch core results in a crash. I have found that disabling Block Transfer GPU allows me to load games without crashing, but this isn't a permanent solution as the crashes still happen somewhat haphazardly and of course several games have graphical problems when this option is turned off.

orbea commented 5 years ago

Savestates work fine for me and Tales of Eternia in the libretro core with RetroArch-1.7.5. Does updating RetroArch help?

ghost commented 5 years ago

Just tried it on RetroArch 1.7.5 with Tactics Ogre and Block Transfer GPU enabled; it's still happening.

orbea commented 5 years ago

I can reproduce this with Tactics Ogre when Block Transfer GPU is enabled, when its disabled the state will load, but the video will be entirely broken (Black screen with spots of partially rendered video).

I'll spend some time getting a backtrace hopefully later today.

orbea commented 5 years ago

Unfortunately the backtrace does not seem very useful despite building both RetroArch and ppsspp with debugging symbols... It seems to crash consistently on 98% though.

Thread 7 "Emu" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffeef17700 (LWP 25778)]
0x00000000410fffff in ?? ()
(gdb) bt
#0  0x00000000410fffff in ?? ()
#1  0x00007fffffffde80 in ?? ()
#2  0x00007fffffffde80 in ?? ()
#3  0x0000000000000018 in ?? ()
#4  0x0000000000000000 in ?? ()
(gdb) bt full
#0  0x00000000410fffff in ?? ()
No symbol table info available.
#1  0x00007fffffffde80 in ?? ()
No symbol table info available.
#2  0x00007fffffffde80 in ?? ()
No symbol table info available.
#3  0x0000000000000018 in ?? ()
No symbol table info available.
#4  0x0000000000000000 in ?? ()
No symbol table info available.
(gdb) t a a f

Thread 7 (Thread 0x7fffeef17700 (LWP 25778)):
#0  0x00000000410fffff in ?? ()

Thread 6 (Thread 0x7fffe63fe700 (LWP 25730)):
#0  0x00007ffff773f2a3 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib64/libpthread.so.0

Thread 4 (Thread 0x7ffff4f0f700 (LWP 25728)):
#0  0x00007ffff773f2a3 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib64/libpthread.so.0

Thread 1 (Thread 0x7ffff4f497c0 (LWP 25665)):
#0  0x00007ffff773f2a3 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib64/libpthread.so.0
orbea commented 5 years ago

When I rebuilt ppsspp with -DUSE_ADDRESS_SANITIZER=ON I got this crash on 99%.

$ ./retroarch
D: zip_read.cpp:267: D: Registered VFS for prefix : /media/data/home/games/bios/PPSSPP/
I: gpu_features.cpp:181: GPU Vendor : nouveau ; renderer: NVF1 version str: 4.3 (Compatibility Profile) Mesa 19.0.0-devel (git-9367514524) ; GLSL version str: 4.30
D: gpu_features.cpp:99: D: Checking for GL driver bugs... vendor=1 model='NVF1'
D: thin3d_gl.cpp:235: D: Shader module created (0x6070002a7b10)
D: thin3d_gl.cpp:235: D: Shader module created (0x6070002a7aa0)
D: thin3d_gl.cpp:235: D: Shader module created (0x6070002a7a30)
D: thin3d_gl.cpp:235: D: Shader module created (0x6070002a79c0)
I: GLRenderManager.cpp:187: Running first frame (0)
=================================================================
==4280==ERROR: AddressSanitizer: heap-use-after-free on address 0x60b000103174 at pc 0x7efed3165090 bp 0x7efee7fa5fd0 sp 0x7efee7fa5fc8
READ of size 2 at 0x60b000103174 thread T6 (Emu)
AddressSanitizer:DEADLYSIGNAL
AddressSanitizer: nested bug in the same thread, aborting.
hrydgard commented 5 years ago

Hm, is that with debug symbols? Surprised that's all the info you're getting...

orbea commented 5 years ago

Yes, I am sure I have debugging symbols for both ppsspp and RetroArch. I built ppsspp with -DCMAKE_BUILD_TYPE=Debug and -O0, gdb reports debugging symbols for both and I got a normal backtrace when I forgot to use -DUSE_ADDRESS_SANITIZER=ON.

This was with ppsspp commit: https://github.com/hrydgard/ppsspp/commit/79d16f7b9f4dd347a1e283e8895629f9d2b7ad2d And RetroArch: https://github.com/libretro/RetroArch/commit/292249b79adbf614823affa5fc8d897cfd98fd2f

orbea commented 5 years ago

Valgrind is also not an option at the moment... https://github.com/libretro/RetroArch/issues/7603

orbea commented 5 years ago

I tried a few games, 7th Dragon 2020 and White Knight Cronicles - Origins crash when loading states, Guilty Gear XX Accent Core Plus and Tales of the World Radient Mythology will load the state fine, but will crash with a similar useless trace when the same state is loaded a second time.

Only Tales of Eternia seemed fine and able to load the same state over and over, but I then decided to leave the town in game where I had saved and enter the world map, loading the same state again resulted in a much more useful crash.

Thread 7 "Emu" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffeef17700 (LWP 31853)]
0x00007fffed3cadd4 in Gen::XEmitter::Write8 (this=0xbbf218, value=243 '\363')
    at /tmp/SBo/ppsspp/Common/x64Emitter.h:362
362     inline void Write8(u8 value)   {*code++ = value;}
(gdb) bt
#0  0x00007fffed3cadd4 in Gen::XEmitter::Write8 (this=0xbbf218, value=243 '\363')
    at /tmp/SBo/ppsspp/Common/x64Emitter.h:362
#1  0x00007fffed3c24ba in Gen::XEmitter::WriteSSEOp (this=0xbbf218, opPrefix=243 '\363',
    op=17, regOp=Gen::X64Reg::ESI, arg=..., extrabytes=0)
    at /tmp/SBo/ppsspp/Common/x64Emitter.cpp:1383
#2  0x00007fffed3c4891 in Gen::XEmitter::MOVSS (this=0xbbf218, arg=...,
    regOp=Gen::X64Reg::ESI) at /tmp/SBo/ppsspp/Common/x64Emitter.cpp:1599
#3  0x00007fffed163e5e in FPURegCache::StoreFromRegister (this=0xbbf798, i=3)
    at /tmp/SBo/ppsspp/Core/MIPS/x86/RegCacheFPU.cpp:723
#4  0x00007fffed1665e3 in FPURegCache::GetFreeXRegs (this=0xbbf798, res=0x7fffeef16274,
    n=1, spill=true) at /tmp/SBo/ppsspp/Core/MIPS/x86/RegCacheFPU.cpp:1079
#5  0x00007fffed166382 in FPURegCache::GetFreeXReg (this=0xbbf798)
    at /tmp/SBo/ppsspp/Core/MIPS/x86/RegCacheFPU.cpp:1044
#6  0x00007fffed1643ff in FPURegCache::MapReg (this=0xbbf798, i=0, doLoad=false,
    makeDirty=true) at /tmp/SBo/ppsspp/Core/MIPS/x86/RegCacheFPU.cpp:611
#7  0x00007fffed33f794 in MIPSComp::Jit::CompFPTriArith (this=0xbbf200, op=..., arith=
    (void (Gen::XEmitter::*)(Gen::XEmitter * const, Gen::X64Reg, Gen::OpArg)) 0x7fffed3c2f10 <Gen::XEmitter::ADDSS(Gen::X64Reg, Gen::OpArg)>, orderMatters=false)
    at /tmp/SBo/ppsspp/Core/MIPS/x86/CompFPU.cpp:75
#8  0x00007fffed33fb0c in MIPSComp::Jit::Comp_FPU3op (this=0xbbf200, op=...)
    at /tmp/SBo/ppsspp/Core/MIPS/x86/CompFPU.cpp:91
#9  0x00007fffed0fceb1 in MIPSCompileOp (op=..., jit=0xbbf240)
    at /tmp/SBo/ppsspp/Core/MIPS/MIPSTables.cpp:922
#10 0x00007fffed158ddc in MIPSComp::Jit::DoJit (this=0xbbf200, em_address=144045640,
    b=0x37180c0) at /tmp/SBo/ppsspp/Core/MIPS/x86/Jit.cpp:360
#11 0x00007fffed15892b in MIPSComp::Jit::Compile (this=0xbbf200, em_address=144045640)
    at /tmp/SBo/ppsspp/Core/MIPS/x86/Jit.cpp:280
#12 0x00007fffed0eae17 in MIPSComp::JitAt ()
    at /tmp/SBo/ppsspp/Core/MIPS/JitCommon/JitCommon.cpp:48
#13 0x000000004010010c in ?? ()
#14 0x00007fffffffdde0 in ?? ()
#15 0x00007fffffffdde0 in ?? ()
#16 0x0000000000000018 in ?? ()
#17 0x0000000000000000 in ?? ()

Full GDB log - https://pastebin.com/WF5WgeDM

orbea commented 5 years ago

I went back to the initial libretro commit and it still occurs with Tactics Ogre. 2a565199b3fc2fe7dad4b63af7b53db577c44c5b

orbea commented 5 years ago

@hrydgard I don't understand the trace very well, but this seems to be an issue with the JIT which the libretro core is just triggering?

unknownbrackets commented 5 years ago

I'd guess that libretro is causing save states to run in parallel to rendering or jit execution, which PPSSPP definitely does not support. That or it's doing it from within a function called by jit, which also isn't acceptable.

The way we process save states (outside libretro) is structured pretty intentionally, and cannot happen while jit is running or from within a function called by jit.

-[Unknown]

orbea commented 5 years ago

@unknownbrackets I think your guesses sound very plausible, I'm not sure the libretro core takes this into account at all.

That said this is unfortunately another issue which I am unlikely capable of fixing myself in the foreseeable future and I am not sure any libretro devs who are capable also care and / or have the time...

klepp0906 commented 5 years ago

just adding another confirm. googled to find out if there was a known easy solution to the problem. At least the powers that be are aware :)

orbea commented 5 years ago

@unknownbrackets Can you remove the No Feedback / Outdated? label?

i30817 commented 4 years ago

@m4wx , this is back... but worse. Now it's savestate, close core and restart core. And it's 'hang' (sometimes one goes through sometimes restart core crashes)

Should this bug be reopened?

orbea commented 4 years ago

@hrydgard There was a second newer issue made for the regression. Probably should only keep one open? https://github.com/hrydgard/ppsspp/issues/13430

i30817 commented 4 years ago

This has more information, i'll close the other.

I'm trying to revert that 'bandaid commit' in HEAD to see if something changes, though i don't expect much.

edit: How do the 'undo load state' and 'undo save state' options work? Is it possible they're making this worse and causing the crash when closing the core/restarting the core by activating a savestate? I find it weird that these seem to be connected, even on those options.

i30817 commented 4 years ago

Ok reverting that commit (almost completely the same) got the savestate running and close core running (i have no idea why?!? What does the savestate has to do with the core closing?).

But the restart core is still crashing.

Obviously considering the comments and warnings this is the wrong approach to do things and probably caused problems too (maybe on load state, haven't tried that). Anyway here is the crash on 'restart' backtrace:

Starting program: /media/i30817/Huginn/Documents/projects/RetroArch/retroarch_x11 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff66be700 (LWP 251411)]
[New Thread 0x7ffff5ebd700 (LWP 251412)]
[New Thread 0x7ffff525d700 (LWP 251413)]
[New Thread 0x7ffff4907700 (LWP 251414)]
[New Thread 0x7fffea2ed700 (LWP 251415)]
[New Thread 0x7fffe9aec700 (LWP 251416)]
[New Thread 0x7fffe92eb700 (LWP 251417)]
[New Thread 0x7fffcffff700 (LWP 251418)]
[Thread 0x7fffe92eb700 (LWP 251417) exited]
[Thread 0x7fffe9aec700 (LWP 251416) exited]
[Thread 0x7fffea2ed700 (LWP 251415) exited]
[Thread 0x7ffff4907700 (LWP 251414) exited]
[Thread 0x7ffff525d700 (LWP 251413) exited]
[New Thread 0x7ffff66be700 (LWP 251419)]
[Thread 0x7fffcffff700 (LWP 251418) exited]
[Thread 0x7ffff5ebd700 (LWP 251412) exited]
[Thread 0x7ffff66be700 (LWP 251411) exited]
[New Thread 0x7fffcffff700 (LWP 251424)]
[New Thread 0x7ffff5ebd700 (LWP 251425)]
[New Thread 0x7ffff525d700 (LWP 251426)]
[New Thread 0x7fffd2981700 (LWP 251427)]
[New Thread 0x7fffd2180700 (LWP 251428)]
[New Thread 0x7fffd197f700 (LWP 251429)]
[New Thread 0x7fffd117e700 (LWP 251430)]
[New Thread 0x7fffd097d700 (LWP 251431)]
[Thread 0x7fffcffff700 (LWP 251424) exited]
[New Thread 0x7fffcd4ca700 (LWP 251432)]
[Thread 0x7ffff5ebd700 (LWP 251425) exited]
[New Thread 0x7ffff5ebd700 (LWP 251434)]
[New Thread 0x7fffcffff700 (LWP 251435)]
[Thread 0x7ffff5ebd700 (LWP 251434) exited]
--Type <RET> for more, q to quit, c to continue without paging--

Thread 19 "Emu" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffcd4ca700 (LWP 251432)]
0x00007fffe810d029 in ?? ()
(gdb) bt
#0  0x00007fffe810d029 in ?? ()
#1  0x00007fffcd4c9f00 in ?? ()
#2  0x00007fffcd4c9f00 in ?? ()
#3  0x00007fffffffda60 in ?? ()
#4  0x00007fffffffda5f in ?? ()
#5  0x00007fffffffda5e in ?? ()
#6  0x00007fffcd4c9cf0 in ?? ()
#7  0x0000000000000000 in ?? ()
(gdb)

Very mysterious you'll agree. I built ppsspp and retroarch with DEBUG=1.

Here is the patch:

d.patch.txt

edit: yeah savestate load crashes with various messages, so basically the patch above is useless. pure virtual method called malloc(): invalid size (unsorted)

maybe more didn't make more saves. Probably the emu threads really do have to be paused to save|replace the state consistently. But doing that is hanging on savestate (and close content? Whyyyy?).

edit2: 'autosavestate when content is closed' in settings->saving is turned off, so i don't really see why this happens except if there is a 'pause' even if that is turned off.

edit3: turning off 'resume content after using save states' in settings->user interface does not help with the crash on loadstate but the crash only occurs when you resume instead of right away (the name is a bit inacurrate but it's supposed to apply to both load and save).

wellerm11 commented 3 years ago

I solved the problem activating fast forward before using the load state

gouchi commented 3 years ago

Is it still an issue ? I can't reproduce the issue on Linux. I can load save state without crashing.

unknownbrackets commented 3 years ago

There was a change recently which might've helped. If people can't reproduce, I'm going to close this (the original author has deleted their account.)

If you're still seeing this same issue, please comment and we'll reopen. If you're seeing a different (even if a bit similar) issue, please open a new issue.

-[Unknown]