[Linux] recording video with output buffer results in segmentation fault

[boringhexi]

What happens?

On my Ubuntu setup, recording a video with the option "Use output buffer (with overlay) for recording" enabled will often result in a segmentation fault. (It creates a video file with a little snippet of video from before the crash.)

When recording, some parts of a game consistently work fine, while other parts will consistently crash. For example (using some games I have on hand):

• Neverland Card Battles demo (ULUS10382): works up until and including the title screen
• Gangs of London demo (UCUS98689): crashes almost immediately
• Gitaroo Man Lives (ULUS10207): can get to the main menu, will crash upon loading or starting a new file. If you begin recording after loading a file, it will make it until it starts a stage.
• Dissidia Final Fantasy demo (NPUH90029): crashes almost immediately
• cube.elf homebrew demo: works and records without any issues

Crash dump/backtrace from gdb (running the Dissidia demo):

(gdb) bt
#0  0x0000555555adaeae in Draw::OpenGLContext::SetScissorRect(int, int, int, int) ()
#1  0x0000555555af8304 in UIContext::BeginFrame() ()
#2  0x00005555556839d8 in EmuScreen::render() ()
#3  0x0000555555af7552 in ScreenManager::render() ()
#4  0x000055555566a376 in NativeRender(GraphicsContext*) ()
#5  0x000055555565561d in MainUI::EmuThreadFunc() ()
#6  0x00007ffff554366f in  () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#7  0x00007ffff4cb86db in start_thread (arg=0x7fffcdd8a700)
    at pthread_create.c:463
#8  0x00007ffff49e188f in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

(There's also a core dump but it's like 870 MB, let me know if anyone's interested.)

What should happen?

Video should record without crashing.

What hardware, operating system, and PPSSPP version? On desktop, GPU matters for graphical issues.

PPSSPP version: Almost-latest from github (was latest as of September 2). Specifically, v1.8.0-605-g9db480757, compiled myself on Ubuntu 18.04.3 LTS

OS version: Ubuntu 18.04.3 LTS

Video hardware: Intel HD Graphics 3000, using OpenGL backend

[hrydgard]

This feels like it's a race condition between two threads or similar.

Core dump is not very interesting but any call stacks from other threads that look relevant would probably be. To switch threads, first type info threads to get a list of threads, then you can switch with like thread 1. After switching threads you can get a backtrace.

There's probably a way to automatically get backtraces from all the threads, too...

I guess I should just try to repro myself later.

[unknownbrackets]

Does this also happen with SDL, or only with Qt?

-[Unknown]

[boringhexi]

@unknownbrackets SDL build also crashes (self-built, actually the latest git this time), it gives basically the same crash dump as the Qt one:

(gdb) bt
#0  0x0000555555b23fee in Draw::OpenGLContext::SetScissorRect(int, int, int, int) ()
#1  0x0000555555b4dcee in UIContext::BeginFrame() ()
#2  0x000055555566b732 in EmuScreen::render() ()
#3  0x0000555555b4c6f2 in ScreenManager::render() ()
#4  0x000055555565251c in NativeRender(GraphicsContext*) ()
#5  0x0000555555ad1655 in EmuThreadFunc(GraphicsContext*) ()
#6  0x00007ffff6a3366f in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#7  0x00007ffff7bbd6db in start_thread (arg=0x7fffeb1a2700) at pthread_create.c:463
#8  0x00007ffff60f088f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

[boringhexi]

@hrydgard I'm not sure what to look for, so I got backtraces of all the threads (self-built latest git)
PPSSPPQt: https://pastebin.com/5GcvYExD
PPSSPPSDL: https://pastebin.com/A3q2EnC8

[unknownbrackets]

My guess is that something (possibly the readback of the output buffer) is clearing the current render target. Probably just need to reassert it somewhere...

This is probably only an issue when hasVisibleUI i.e., when you have the FPS enabled or etc. That may be why it hasn't been as noticeable. Doesn't look like a threading issue from those backtraces.

-[Unknown]

[hrydgard]

Ah good thinking, forgot it could be that... very possible.

[unknownbrackets]

So basically, we would grab the frame during the hleLeaveVblank event (end of vblank), but the exact timing of CORE_NEXTFRAME depends on how the game flips buffers. But there's definitely a chance they're bundled together.

That's the scenario in which it'd crash. I think the simplest thing is just a draw_->BindFramebufferAsRenderTarget(nullptr, KEEP... when hasVisibleUI() is true. In most cases it'd be ignored, right?

-[Unknown]

[hrydgard]

Yeah, I guess that would be fine.

[unknownbrackets]

Does this work fine now in the latest git build?

-[Unknown]

[boringhexi]

Sorry for the delay, I will be testing it now.