libTAS
libTAS copied to clipboard
Savestates always crashing
Long story short any version of Ruffle I run will crash upon trying to load a savestate, doesn't matter what game, doesn't matter what version, doesn't matter what settings I adjust, it will crash. output of "uname -rvmpio": 6.1.1-1-MANJARO #1 SMP PREEMPT_DYNAMIC Wed Dec 21 23:21:50 UTC 2022 x86_64 unknown unknown GNU/Linux
Attached is an error log of me attempting to run ratmaze2 via ruffle-nightly-2023_01_26-linux-x86_64, command line options in libTAS are: "-g gl ../../ratmaze2.swf". I saved a state on frame 4, loaded on frame 5. I've also attached the swf for ease of debugging, although I can not stress enough this happens on literally any flash game or file through Ruffle.
This also happened on my previous computer which was also 64 bit Manjaro, that one had an Nvidia card, this new one has an AMD card. Any suggestions or possible causes would be appreciated. Thank you
Great news, just went back and tested on some other games/apps, literally anything crashes upon attempting to load a save state, Super Hexagon, Tile World 2.2.0, anything I attempted to save and load in crashed with a "*** stack smashing detected ***: terminated" upon loading a state.
Are you using a laptop? This stack smashing always happens to me on my laptop.
I’m not, although my old system was technically a laptop and it did crash there. But yeah current system isn’t and it’s stack smashing, I wonder if it’s an Arch/Manjaro issue?
I think the cause of this is some kind of werid incompatibility/bug with running libTAS on modern CPUs, from around ~2020 onward. The moment I first tried using savestates after upgrading my CPU from Zen 2 to Zen 3, I encountered this bug. Nothing changed on the software side.
The old laptop I had was a gen 6 Intel i5, the current one is a modern AMD Ryzen 9 5900X. Both ran Manjaro, issue certainly seems to be somewhere in software
I pushed a branch (https://github.com/clementgallet/libTAS/tree/stacksmashing) that prints some information about the stack protection value (canary). For people that has the issue, can you compile that branch, then:
- launch libTAS from a terminal
- run any 64-bit game
- save a state and load it
- it should print some memory content on the terminal (it will print with Info tag which should be checked by default), paste it here
Here's a couple tests, same version of Ruffle and same game as the first post, saved frame 5 attempted to load frame 6: stack_smash_ratmaze2.txt
Here's Super Hexagon, saved frame 1 load frame 2: stack_smash_hex.txt
And here's one on a custom version of Tile World 2.2.0: stack_smash_tw2.txt
Hope this is of use, will gladly run any other tests or commits that you propose, thank you!
Thanks! The stack layout seems completely different from my version. Could you post here the libtas build as well (both libTAS
and libtas.so
)?
In case it helps, it happens for me as well:
Linux 6.1.6-arch1-3 #1 SMP PREEMPT_DYNAMIC Mon, 16 Jan 2023 12:51:23 +0000 x86_64 GNU/Linux
on a Ryzen 7 7700X.
The code I ran is using winit + wgpu
, same as ruffle: gfx-rs/wgpu/examples/boids.rs with WGPU_BACKEND=gl ./boids
cargo build --example boids --release
.
libTAS
and libTAS.so
: https://easyupload.io/m/ng8jz5
Thanks! The stack layout seems completely different from my version. Could you post here the libtas build as well (both
libTAS
andlibtas.so
)?
Sure thing: libTAS Stack Build.zip
I'm also more than happy to provide any .o files, any assembly outputs, anything like that it would help
Thanks! Unfortunately, the memory being printed is completely different from by computer, so i guess the aycliffe calls are being different. I can't use these results :(
This should be fixed by 62c6da0a0cda7862c571fdc60531dc101cd69d25
Yep, that commit seems to fix it, at least on Ruffle with Vulkan drivers. ~~Yet to test games such as FTL: Faster Than Light with this commit, though.~~
Edit 1: Doesn't crash on Ruffle using Mesa drivers. Edit 2: Also doesn't crash in FTL.
I second this, stack smashing was eliminated on ruffle with -g gl for me