LibTAS + ScummVM fullscreen Videos crash game.

[darkshoxx]

Originally posted here https://bugs.scummvm.org/ticket/14445 as I didn't know if it was a ScummVM or LibTAS issue. Copy-pasted from the submission over there

tested it on 2 diffent systems:

Win 11, running Ubuntu jammy 22.04 via WSL 2 + XLaunch. ScummVM 2.7.0 (Feb 18 2023 23:18:27) [my system, darkshoxx]
Native Linux Mint 21.1 Cinnamon, 2.8.0git (Apr 5 2023 13:54:37) [someone else's system] 

In either case, running LibTas Version v1.4.4

On my system it was tested in Gabriel knight 2, Shivers 1, Phantasmagoria 1 and 2. On someone else's system it was tested on Gabriel Knight 1.

The following occurs

LibTAS booting the game, setting a safestate before playing a fullscreen video, , loading the savestate and then playing the video causes the game to freeze or crash. LibTAS itself will not crash. The error Message is along the lines of:

X Error of failed request: GLXBadContext Major opcode of failed request: 155 (GLX) Minor opcode of failed request: 183 (X_GLXIsDirect) Serial number of failed request: 181 Current serial number in output stream: 31

Ignore the exact numbers, that's copy pasted from a different thread.

What we HAVE figured out, is that it DOESN'T crash if the video is in half-video mode, such as is choosable in Phantasmagoria 1.

To replicate: Install LibTAS v 1.4.4 ​https://clementgallet.github.io/libTAS/ run LibTAS, untick pause checkbox, add phantas 1 (or any of the other games) to game list, click until in main menu. press SHIFT+F1 to make a savestate. Press F1 to LOAD that same savestate. Click "Watch Intro". If the game is set to full-video it will crash. If it's set to half-video (accessible from the game options mid gameplay, not accessible from the main menu), it will not crash. If no savestate is made or loaded, it will not crash. If the savestate is made, but NOT loaded, it will NOT crash.

Given that the crash also happen on Mint, I thought to rule out WSL, XLaunch, and specific Ubuntu version. We also tried Riven, which begins with a fullscene Cutscene, and it doesn't crash (wth savestates and all). So I was asssuming it is to do with the interaction between ScummVM SCI engine and LibTAS. But I don't know on which side the "discrepancy" happens. In fact I know nothing, I am just guessing, and providing you with as much info as I can. Like, there's a chance that this is a LibTAS bug, and has nothing to do with ScummVM. Just in case, I'll flag it as a bug here.

If it's of any help, we went bughunting during this stream: ​https://www.twitch.tv/videos/1810457370 and it happens pretty much right away.

I currently don't know where the scummvm logs are on linux, If you let me know, I can attach them.

To be sure, the game does not crash if ScummVM is run WITHOUT LibTAS. LibTAS Log Excerpt.txt Added part of the log file of the crash, manually stopped, then killed the game. I also did a run where I set "log to file" but I don't know where that file is. If someone can point me to it, I can upload that as well.

Also, 20 minutes later, my PC crashed with BSOD. Not sure if related, but you know, memory leaks and such. No clue.

[darkshoxx]

Quick update, the bugreport on ScummVM has received a reply, pretty much stating the ball is in LibTAS' court for now, with some info on what may be happening. Quote:

It's my understanding from the description that this is an interoperability problem between LibTAS and ScummVM. I had never heard of LibTAS before, and I wouldn't assume anyone else here has. Reading about LibTAS, it seems that this is a program that is able to freeze arbitrary programs, record their internal states, and later freeze them and restore these internal states and then let them run. THAT IS INSANE! It's also cool! BUT IT'S INSANE. If LibTAS is failing at the insane task that they've made it their business to undertake, against all medical advice, I feel like it should be brought up with them first. A lot of developers would read that description and say, "A third party program screwed around with our RAM while we were running, crashed our program, and we have a bug?", and that would be the end of it. But let's keep this open just in case I've mischaracterized this. It could be that ScummVM code is calling some low level graphics API in an incorrect way that leads to this crash. But it's a lot more likely that the external program that's messing around with our internals at runtime is doing so badly. (Because there's no "good" way to do that!) Either way, I think the ball is in LibTAS' court. I don't think this has any relationship to the SCI engine code, but SCI does change video modes in these games, so that seems like the relevant issue. I'm kicking this to Graphics but that's kind of a guess; the least-inaccurate option.

I hope this is helpful. It's really only this issue preventing me from making more TASes of Sierra Point'n'Clicks

[clementgallet]

Posted also in scummvm ticket:

Looking at this issue: when the Phantasmagoria 1 intro cutscene starts, scummvm is calling SDL_DestroyRenderer() then SDL_CreateRenderer() on the current window, which calls the underlying glXDestroyContext() and glXCreateContext() functions.

When a savestate is saved before the cutscene, we play the cutscene, the savestate is loaded and we play again the cutscene, the SDL renderer is destroyed a second time. This is no problem for SDL because the old context was recovered as part of the savestate loading. However, GLX contexts are shared with X server, so when a request is sent to destroy the context, the server reports that the context is bad (already destroyed).

[darkshoxx]

Thank you for figuring out the core of the issue. Can it be fixed? If so, where?

[darkshoxx]

shameless PING before I try this again

[vadosnaprimer]

For context: this submission would benefit greatly from this fix https://tasvideos.org/8249S