Linux build crashes on shutdown/relaunch

[NostalgiaRealm]

I built Casterlabs Caffeinated from source on my Fedora Linux 44 box on Wayland and created the Linux build with:

export JAVA_HOME=/usr/lib/jvm/java-11-temurin-jdk
export PATH="$JAVA_HOME/bin:$PATH"

bash ./build.sh compile
bash ./build.sh dist-linux

I had to use an older Java version, the bundling script targets Java 11. The build would not succeed without specifying this older Java version.

This Linux build can launch successfully. However, after closing the app once, the JVM crashes. After that, later launches often crash immediately :(

Terminal log after closing down Caffeinated

[INFO  ] [Bootstrap] Shutting down.
[SEVERE] [Rakurai RakuraiHttpServer] An error occurred whilst accepting a new connection:
[SEVERE] [Rakurai RakuraiHttpServer] java.net.SocketException: Socket closed
[SEVERE] [Rakurai RakuraiHttpServer]    at java.base/java.net.PlainSocketImpl.socketAccept(Native Method)
[SEVERE] [Rakurai RakuraiHttpServer]    at java.base/java.net.AbstractPlainSocketImpl.accept(Unknown Source)
[SEVERE] [Rakurai RakuraiHttpServer]    at java.base/java.net.ServerSocket.implAccept(Unknown Source)
[SEVERE] [Rakurai RakuraiHttpServer]    at java.base/java.net.ServerSocket.accept(Unknown Source)
[SEVERE] [Rakurai RakuraiHttpServer]    at co.casterlabs.rhs.impl.RakuraiHttpServer.doRead(RakuraiHttpServer.java:63)
[SEVERE] [Rakurai RakuraiHttpServer]    at co.casterlabs.rhs.impl.RakuraiHttpServer.lambda$start$2(RakuraiHttpServer.java:438)
[SEVERE] [Rakurai RakuraiHttpServer]    at java.base/java.lang.Thread.run(Unknown Source
[INFO  ] [LocalServer] Stopped!
[INFO  ] [AppAuth] Signin cancelled (?)
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fb15b6a1e1e, pid=13747, tid=13747
#
# JRE version: OpenJDK Runtime Environment Temurin-11.0.31+11 (11.0.31+11) (build 11.0.31+11)
# Java VM: OpenJDK 64-Bit Server VM Temurin-11.0.31+11 (11.0.31+11, mixed mode, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# C  [libsaucer.so+0x4c6e1e]  std::__uniq_ptr_impl<saucer::application::impl::native, std::default_delete<saucer::application::impl::native> >::_M_ptr() const+0x18
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %d %F" (or dumping to /home/rick/caffeinated/dist/build/gnulinux-x86_64/core.13747)
#
# An error report file with more information is saved as:
# /home/rick/caffeinated/dist/build/gnulinux-x86_64/hs_err_pid13747.log
#
# If you would like to submit a bug report, please visit:
#   https://github.com/adoptium/adoptium-support/issues
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Aborted                    (core dumped) ./Casterlabs-Caffeinated

Crash log on subsequent launches: hs_err_pid14235.log

As a test, I asked ChatGPT to look at this issue. The clanker did spit out fixed files, which did no result in much improvement on my end. This is what the clanker changed:

Title: Linux WebKitGTK build crashes on shutdown/relaunch on Fedora 44 and Debian 13

I built Casterlabs Caffeinated from source and created the Linux build with:

bash ./build.sh compile
bash ./build.sh dist-linux

The Linux build can launch successfully on modern Linux when using the WebKitGTK backend, especially under Wayland. However, after closing the app once, the JVM crashes in native Saucer/WebKitGTK code. After that, later launches often crash immediately.

Tested environments:

Fedora 44, KDE Plasma Wayland
Debian 13 Trixie in distrobox on Fedora 44 host
Java runtime bundled by the app: Temurin 11.0.31
Saucer backend: WebKitGtk
Saucer version shown at runtime: 8.0.2

The app reaches a successful running state:

[INFO  ] [Bootstrap] SaucerApp.backendType()      | WebKitGtk
[INFO  ] [Bootstrap] Starting app...
[INFO  ] [Bootstrap] Calling run() loop...
[INFO  ] [LocalServer] Started!
[INFO  ] [Bootstrap] Everything is running and everything is happy :D

But when the app is closed, it crashes during native shutdown:

[INFO  ] [Bootstrap] Shutting down.
[INFO  ] [LocalServer] Stopped!
[INFO  ] [AppAuth] Signin cancelled (?)

#

# A fatal error has been detected by the Java Runtime Environment:

#

# SIGSEGV

# Problematic frame:

# C  [libsaucer.so+0x4c6e1e] std::__uniq_ptr_impl<saucer::application::impl::native, std::default_delete[saucer::application::impl::native](saucer::application::impl::native) >::_M_ptr() const+0x18

Forced X11 is worse: it crashes immediately in libwebkitgtk-6.0.so.4. Wayland is the only backend where the app reliably gets to the running state.

There is also a smaller startup issue:

java.nio.file.NoSuchFileException: ~/.local/share/casterlabs-caffeinated/ipc

That directory should probably be created before registering the filesystem watcher.

Suggested code-level fixes:

1. Make Linux shutdown idempotent.

* Ensure shutdown can only run once, for example with an AtomicBoolean.
* Prevent both the native WebKitGTK close callback and Java shutdown path from destroying the same Saucer window/application.

2. Do not call saucer.window.destroy() from normal Java hide/close handling on Linux.

* The crash appears to happen when Saucer/WebKitGTK is already closing or has partly torn down native state.
* Window close should trigger app shutdown, but should not also directly destroy the native Saucer object from multiple paths.

3. Handle the Saucer close callback more defensively.

* On Linux/WebKitGTK, return a value that prevents the native window from being destroyed automatically while Java shutdown is starting.
* Start shutdown on a separate Java thread and let the process exit cleanly after Java-side cleanup.

4. Reconsider calling SaucerApp.quit() during final Linux shutdown.

* On modern WebKitGTK 6 this appears to enter unsafe native cleanup.
* If Saucer cannot safely shut down on Linux, a pragmatic workaround is to finish Java cleanup and then terminate the process without re-entering Saucer destruction.
* The ideal fix is to update Saucer/Saucer4J or fix the destruction order upstream.

5. Create the IPC directory before watching it.

* Before registering the WatchService for ~/.local/share/casterlabs-caffeinated/ipc, call Files.createDirectories(ipcPath).

6. Prefer Wayland on Linux for this build.

* A wrapper script or launcher environment should set:

GDK_BACKEND=wayland
WEBKIT_DISABLE_DMABUF_RENDERER=1

* Avoid forcing GDK_BACKEND=x11, because that crashes immediately in WebKitGTK 6 on my setup.

Files likely involved:

app/core/src/main/java/co/casterlabs/caffeinated/app/AppWindow.java
app/core/src/main/java/co/casterlabs/caffeinated/bootstrap/Bootstrap.java
app/core/src/main/java/co/casterlabs/caffeinated/bootstrap/IPCWatcher.java
build.sh or Linux launcher generation

Expected behavior:

* App launches on Fedora 44 and Debian 13.
* Closing the window exits cleanly.
* Relaunching works repeatedly.
* No SIGSEGV in libsaucer.so or libwebkitgtk-6.0.so.4.
* No missing ipc directory exception on startup.

[e3ndr]

Yeah it's a known issue with it at the moment. Tell the clanker to try out a headless JVM build. From what I could tell during development, the issue is with GTK2 (AWT) clashing with GTK3 (Saucer). I haven't had much time to debug the linux version :p

Might also be worth trying to convince it to run the Windows version with wine. The only roadblock there is the dependency on WebView2 which I believe can be worked around with enough winetricks magic.

[NostalgiaRealm]

No dice with the headless JVM. I let the clanker spit out a command to create a custom Java 11 runtime WITHOUT java.desktop / AWT / Swing. Then used that as the app runtime, but the same issue. Caffeinated does run fine in Wine currently without any modification, albeit with some minor quirks: 1) missing text sometimes, but fixed when resizing the windows 2) When chat alerts are set as a browser source in OBS, and message animation is set to Slide-in, the slide-in effect is extremely slowww.

I just installed WebView2 from here to my Wine prefix, see if that changes things a bit :)
(WebView is not available in Winetricks just yet)
https://developer.microsoft.com/en-us/microsoft-edge/webview2

[e3ndr]

Awesome. Are you running the windows version from the website or did you compile it from here? The current one on the website is pinned to the legacy branch which does not depend on WebView2.

1. missing text sometimes, but fixed when resizing the windows

Could you screen record this behavior?

2. When chat alerts are set as a browser source in OBS, and message animation is set to Slide-in, the slide-in effect is extremely slowww.

Refresh the source in OBS a few times. It's a weird timing bug.

[NostalgiaRealm]

Awesome. Are you running the windows version from the website or did you compile it from here? The current one on the website is pinned to the legacy branch which does not depend on WebView2.

I previously only tried to use the Windows build from the website.
When manually building Initially, the Windows build did not compile with the default Windows build target on Linux. I had to use dist-nosign-windows for it to compile successfully. Only thing that then won't work then is the inclusion of an embedded icon. But that's a non-issue.

Unfortunately, the build this produces crashes with a fatal error in WMC-JsonConsoleWrapper. Even with the WebView2 Runtime installed successfully (Evergreen Standalone Installer).

The version on the website works fine, but with the aforementioned issues. With that said, currently the text does show up correctly. It just takes a second or 2 to fully render all text. So for 2 seconds, when switching between tabs, the window could look like this: (testing done on Wine 11.11)

[e3ndr]

Yeah. The current version on the website has dog-slow IPC which is exacerbated by Wine.

As for the WMC issue, you should be able to delete that .exe in the generated zip and run without it. It doesn't do anything on Linux anyway :p

If that doesn't work, there's a chance you could get it working by playing around with your .NET runtimes. WMC is written in .NET and bundled as a fat single exe rather than a multi-DLL one (like is common for most .NET apps).

[NostalgiaRealm]

Ha, alright! Unfortunately the issue remains even with WMC-JsonConsoleWrapper.exe removed. I do see Caffeinated in the system tray, but the GUI never opens up.

I tried installing .NET Core Desktop Runtime 10.0, that didn't improve things. So I tried installing a bunch of different runtimes with no different results. I even built the project again on Windows instead to see if that would change things, but same result once run on Wine. It seems that it's a dead end. For now I'll just run the older release from the website using Wine :)