[SOLVED] Vital crashes when opening GUI on saved project

Vital works fine in the session it’s first added to the plugin chain, but if I save the project, open it again, and then open the GUI, then it crashes with the following:

About to start the following process:  /opt/bitwig-studio/bin/BitwigPluginHost64 host Matt-Tytel 48000 1024 3586-9 8 not-dpi-aware 5 HDA Intel PCH;ALC3232 Analog;HDA:10ec0292,17aa220e,00100001;HDA-Intel;0;0 HDA Intel PCH / ALC3232 Analog
Creating plugin audio thread proxy 0
PluginHost: Starting new audio thread for processing plugin 0
Error setting realtime priority for thread to -1
PluginHost: Loading initial plugin state: /home/user/.BitwigStudio/plugin-states/bdcfa72d-c7cd-4352-b70d-9889f3fe9f9b.fxb
Applying plugin IO state
Applying plugin instance state
[xcb] Unknown sequence number while processing reply
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
BitwigPluginHost64: ../../src/xcb_io.c:641: _XReply: Assertion `!xcb_xlib_threads_sequence_lost' failed.
Could not read async reply: End of stream
Killing pluginhost process
Could not process audio on client audio thread 1 using remote audio thread 0: End of stream
Waiting for plugin host process to exit
Plugin host process exited with code: 134

Scratch that. Now Vital doesn’t even open on a fresh project. Used to. No idea what changed. Haven’t updated anything since a few days ago when it was working just fine.

Okay, got a dump:

(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007f52cd551859 in __GI_abort () at abort.c:79
#2  0x00007f52cd551729 in __assert_fail_base (fmt=0x7f52cd6e7588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7f52c6049858 "!xcb_xlib_threads_sequence_lost", file=0x7f52c60496c3 "../../src/xcb_io.c", line=641, function=<optimised out>) at assert.c:92
#3  0x00007f52cd562f36 in __GI___assert_fail (assertion=0x7f52c6049858 "!xcb_xlib_threads_sequence_lost", file=0x7f52c60496c3 "../../src/xcb_io.c", line=641, function=0x7f52c6049ad8 "_XReply") at assert.c:101
#4  0x00007f52c5fd60ee in _XReply () at /lib/x86_64-linux-gnu/libX11.so.6
#5  0x00007f52c4b7bd3e in  () at /lib/x86_64-linux-gnu/libGLX_nvidia.so.0
#6  0x00007f52c4b13824 in  () at /lib/x86_64-linux-gnu/libGLX_nvidia.so.0
#7  0x00007f52c4b42253 in  () at /lib/x86_64-linux-gnu/libGLX_nvidia.so.0
#8  0x00007f52c4b47248 in  () at /lib/x86_64-linux-gnu/libGLX_nvidia.so.0
#9  0x00007f52c4b38e16 in glXCreateContextAttribsARB () at /lib/x86_64-linux-gnu/libGLX_nvidia.so.0
#10 0x00007f52c69be4fc in  () at /lib/x86_64-linux-gnu/libGLX.so.0
#11 0x00007f52bebae0c7 in juce::OpenGLContext::CachedImage::runJob() () at /home/entropy/tracks/VST/Vital.so
#12 0x00007f52be96f96a in juce::ThreadPool::ThreadPoolThread::run() () at /home/entropy/tracks/VST/Vital.so
#13 0x00007f52be9707f7 in juce::threadEntryProc(void*) () at /home/entropy/tracks/VST/Vital.so
#14 0x00007f52cd887609 in start_thread (arg=<optimised out>) at pthread_create.c:477
#15 0x00007f52cd64e103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb)

Solved: This issue is fixed in Bitwig 3.3.1