[GTK3] Gdk-CRITICAL from gdk_threads_set_lock_functions when a second Display is created in the same JVM

[minduch]

Describe the bug

On Linux/GTK3, SWT emits a Gdk-CRITICAL from gdk_threads_set_lock_functions when a
second Display is created in the same JVM:

(SWT:3525662): Gdk-CRITICAL **: 15:17:08.404: gdk_threads_set_lock_functions: assertion 'gdk_threads_lock == NULL && gdk_threads_unlock == NULL' failed

gdk_threads_set_lock_functions() has been deprecated since GTK 3.6, and its
implementation asserts that the lock functions have not already been installed, so the
assertion fails on any call after the first one in a process.

Nothing fails as a result — the process does not crash and the second Display works —
but the CRITICAL is emitted on stderr on every affected run, which makes it noise in
build logs where a real GTK CRITICAL would matter.

Reproduced with a standalone snippet outside Eclipse, on two machines: aarch64 on bare
metal with a working NVIDIA GL stack, and x86_64 in a VMware guest with 3D acceleration
disabled and Mesa falling back to software rendering. Architecture, GL stack and
virtualisation therefore do not matter. Both machines do run the same GTK build
(3.24.41-4ubuntu1.3) and the same JDK, so those are not ruled out — though given that
gdk_threads_set_lock_functions() asserts on any second call by design, a GTK version
dependency seems unlikely. Originally noticed during Tycho UI test runs
(org.eclipse.tycho.surefire.osgibooter.uitest), which provision an Equinox workbench
per test module, but the snippet below reproduces it with no Equinox, no Tycho and no
WebKit in the process.

To Reproduce

Run this on Linux/GTK3, with only the platform fragment on the classpath:

import org.eclipse.swt.widgets.Display;

public class Snippet {
    public static void main(String[] args) {
        Display d1 = new Display();
        d1.dispose();
        Display d2 = new Display();   // Gdk-CRITICAL is emitted here
        d2.dispose();
    }
}

Verified output, with markers added around each step to establish exactly where the
message is emitted:

=== PROBE 1: before first Display ===
=== PROBE 2: first Display created ===
=== PROBE 3: first Display disposed ===
(SWT:3525662): Gdk-CRITICAL **: 15:17:08.404: gdk_threads_set_lock_functions: assertion 'gdk_threads_lock == NULL && gdk_threads_unlock == NULL' failed
=== PROBE 4: second Display created ===
=== PROBE 5: done ===

The first Display is clean; the CRITICAL comes from the second one.

Expected behavior

Creating a second Display in the same process should not cause GTK to emit a
CRITICAL. gdk_threads_set_lock_functions() has been deprecated since GTK 3.6 and
asserts on any call after the first; SWT should either stop calling it or guarantee it
is called at most once per process.

Screenshots

Not applicable — the symptom is stderr output.

Environment:

1. Select the platform(s) on which the behavior is seen:

• • All OS
• • Windows
• • Linux
• • macOS

2. Additional OS info (e.g. OS version, Linux Desktop, etc)

   Machine A (aarch64, bare metal) — original observation, Tycho UI test run:
   Ubuntu 24.04.4 LTS, aarch64, kernel 6.17.0-1031-nvidia.
   GTK 3.24.41-4ubuntu1.3 (libgtk-3-0t64:arm64). No GTK4 package installed,
   SWT_GTK4 unset, so this is the GTK3 binding.
   Real X session: XDG_SESSION_TYPE=x11, Xorg on vt2 under gdm, DISPLAY=:0.
   Not headless, not Xvfb, not Xwayland.
   NVIDIA GPU present (PCI 10de:2e12), hardware GL functional.

   Machine B (x86_64, VMware guest) — standalone snippet verified here:
   Ubuntu 24.04.4 LTS, x86_64, 3D acceleration disabled in the hypervisor.
   GTK 3.24.41-4ubuntu1.3 (libgtk-3-0t64:amd64), SWT_GTK4 unset.
   Real X session: XDG_SESSION_TYPE=x11, DISPLAY=:0.
   Mesa cannot obtain a DRI3/DRI2 device and falls back to software rendering.

3. JRE/JDK version

   Eclipse Temurin 25.0.4.1+1 (OpenJDK 25.0.4.1 LTS) on both machines —
   aarch64 on Machine A, x86_64 on Machine B.

Version since

Unknown — this is first-observed, not a regression point. First seen with SWT 3.135.0
on the Eclipse 2026-09 RC1 (4.41) target platform; resolved bundle qualifier
3.135.0.v20260819-1952, from the 2026-09/202608281000 composite repository. Not checked
against earlier SWT versions.

Workaround (or) Additional context

No workaround known; the message is diagnostic only and nothing observable fails.

This is a pre-release target platform (2026-09 RC1), not a final release build.

Regarding the WebKit note in the issue template: this is not a crash, so
#843 does not apply. The
verified snippet creates no Browser widget and no WebKit process exists in it.

One further message appears in the Tycho runs on both machines. It is noted here only
so it is not mistaken for part of this issue:

• Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -1 and height -1 — does not occur in the standalone snippet above, so it is a separate
  issue and is not reported here.