Pasting in a few kb of text locks up FrooxEngine on Linux

[mxjessie]

Describe the bug?

I was trying to paste in the entirety of the source code of the classic glxgears GL demo application circa 1999 and every time it would lock up FrooxEngine with an Aborting ProtoFlux contexts error. The renderer and audio threads continue to run.

To Reproduce

Copy the contents of gears.c from here.

Attempt to paste it into Resonite. For me, it freezes instantly.

Reproduction Item/World

https://gitlab.freedesktop.org/mesa/demos/-/blob/038100d965539d768d1ae51b217f52dda877dc56/src/demos/gears.c (linked above)

Expected behavior

It shouldn't do that. I do expect tens-to-hundreds-of-kb text file imports to be very laggy when spawned in, but not application-freezingly so.

Screenshots

Resonite Version Number

Beta 2025.9.12.1173

What Platforms does this occur on?

Linux

What headset if any do you use?

Quest 2

Log Files

spincoat - 2025.9.12.1173 - 2025-09-21 00_54_11.log

Additional Context

Also able to reproduce this with the stock text import UI.

Reporters

qualia (qualium on Discord)

[github-actions[bot]]

Hello! Here are the results of the automated log parsing:

Version	OS	CPU	GPU	VRAM	RAM	Headset	Plug-ins/Mods	Renderer	Clean Exit
Beta 2025.9.12.1173	Steam Runtime	Intel(R) Xeon(R) W-2275 CPU @ 3.30GHz	TU104 [GeForce RTX 2080 SUPER] (rev a1)	0.00 B	62.52 GB	SteamVR	no	Renderite.Renderer.Unity 2025.9.2.419 (2019.4.19f1) (WindowPtr: 0x300B0	❌

---

This message has been auto-generated using logscanner.

[yoshiyoshyosh]

I can reproduce this bug. It appears to happen when pasting 8185 or more bytes.

Running this (replacing xclip with the wayland equivalent) and pasting the output will not produce the bug:

cat /dev/urandom | tr -Cd a-zA-Z0-9 | head -c 8184 | xclip -sel clipboard

While changing the 8184 to 8185 will. This is exactly 12 bytes off of 8192, so I suspect some buffer somewhere is not happy.

[jvyden]

This is the buffer size of the bootstrapper's IPC to FrooxEngine being exceeded and silently ignored - the buffer size is only 8196.

FrooxEngine seemingly synchronously waits for clipboard data from the IPC, but on the bootstrapper side it hits an exception since there's not enough space for the message in the buffer, so it sends nothing. FrooxEngine then hangs while waiting.

That's my hypothesis on the FrooxEngine side anyways. I had investigated this a while ago with Cyro but I forgot to report anything since I hadn't updated to the prerelease with the new clipboard stuff yet :s

[ProbablePrime]

@BlueCyro This sounds like something you would be able to take a look at.

[BlueCyro]

Getting back into the swing of things. Will look at this later today

[mxjessie]

This appears to be fixed in the .NET 10 prerelease (Beta 2025.11.19.26), but not on the current release branch. I was even able to paste in some rather longer texts. (I do still need the ResoniteLinuxClipboard mod to paste, per #4974). If this is expected, I think this can be closed once prerelease lands.

[mxjessie]

OK, we're all good here on release, marking as done. Thanks @BlueCyro!

[yoshiyoshyosh]

This is not fixed for me on the .NET 10 build unmodded. Text with a length > 8184 will still freeze. Meant to respond to this earlier but forgot. My bad.

I captured a dotnet-trace of the freeze, should it help at all (open in speedscope.app). It seems to be infinitely awaiting for the task spawned from FrooxEngine.BootstrapperManager.GetClipboardText(), which is consistent with jvyden's comment from above.

[mxjessie]

Can confirm: without mods, yosh's reproduction command above (s/xclip.*/wl-copy/ if Wayland) does still trigger this freeze; my bad

[yoshiyoshyosh]

Ever since the switch to the new clipboard stuff, this issue specifically no longer occurs, so it can be closed now.