Savestates always crashing about libtas

[SicklySilverMoon]

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.

[LukeSaward1]

Are you using a laptop?
This stack smashing always happens to me on my laptop.

[SicklySilverMoon]

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?

[P-AS]

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.

[SicklySilverMoon]

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

[clementgallet]

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

[SicklySilverMoon]

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!

[clementgallet]

Thanks! The stack layout seems completely different from my version. Could you post here the libtas build as well (both libTAS and libtas.so)?

[jakobhellermann]

In case it helps, it happens for me as well:

logs.txt

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

[SicklySilverMoon]

Thanks! The stack layout seems completely different from my version. Could you post here the libtas build as well (both libTAS and libtas.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

[clementgallet]

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 :(

[CasualPokePlayer]

This should be fixed by 62c6da0

[LukeSaward1]

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.

[Futurama39]

I second this, stack smashing was eliminated on ruffle with -g gl for me