GRAPHICS: libTAS crashes SCI with fullscreen video

[darkshoxx]

This might be complicated, sorry Sluicebox.
We've narrowed it down quite a bit already, and tested it on 2 diffent systems:

1. Win 11, running Ubuntu jammy 22.04 via WSL 2 + XLaunch. ScummVM 2.7.0 (Feb 18 2023 23:18:27) [my system, darkshoxx]
2. 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.

[darkshoxx]

It appears that running ScummVM with LibTAS does not update the log files, at least not the one I found in ~/.cache/scummvm/logs

But I got an actual "traceback" of my error from my system, not copied from somewhere else to add:

X Error of failed request: GLXBadContext

Major opcode of failed request: 149 (GLX)
Minor opcode of failed request: 4 (X_GLXDestroyContext)
Serial number of failed request: 2294
Current serial number in output stream: 2295

[darkshoxx]

Hi, I don't know if this is allowed or bad manners or something, but I thought I'd ping here real quick for a response before trying support somewhere else.

[sluicebox]

Hello! Perfectly appropriate to ping a ticket if it's not moving.

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.

[darkshoxx]

Hi, sorry for the late response.
Yes, LibTAS is used to make TAS speedruns, which controls actions one frame at a time. Indeed, the way I understand it is the way you describe it with saving and restoring internal states.
I have since made an Issue on LibTAS' git
​https://github.com/clementgallet/libTAS/issues/540
and will update it with your response.
Is there anything you can tell us about the difference between the full- and half-screen video mode in phantasmagoria, any flags, adresses, or something else to look into that would pertain only to fullscreen but not halfscreen mode that might help them figure out the issue?

[clementgallet]

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).