Bug 2521651

Summary: webkitgtk 2.53.91: RELEASE_ASSERT in WTF::initializeMainThread aborts Eclipse — WebKit initialized on non-original thread (uid != 1)
Product: [Fedora] Fedora Reporter: mark97753
Component: webkitgtkAssignee: Michael Catanzaro <mcatanza>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 45CC: daniel, gnome-sig, mark97753, mcatanza, suraj.ghimire7, tpopela
Target Milestone: ---Keywords: Desktop, Regression
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2026-09-17 21:21:08 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
gdb backtrace and thread list from core (PID 43926) none

Description mark97753 2026-08-23 16:56:09 UTC
Eclipse IDE (Oracle OUAF SDK 25.4 bundle, Eclipse 4.40 / SWT 3.134.0) aborts on Fedora 45 whenever SWT initializes the internal browser. The crash is entirely inside WebKit — no Eclipse or SWT frame is involved beyond the JNI entry point.

The same Eclipse installation, unchanged, worked on Fedora 44.

Source/WTF/wtf/MainThread.cpp:47
RELEASE_ASSERT(!isMainThread() || Thread::currentSingleton().uid() == 1);

42      static std::once_flag initializeKey;
43      std::call_once(initializeKey, [] {
44          initialize();
45          initializeMainThreadPlatform();
46          RunLoop::initializeMain();
47          RELEASE_ASSERT(!isMainThread() || Thread::currentSingleton().uid() == 1);
48      });
49  }

BackTrace:

#0  __pthread_kill_implementation () at pthread_kill.c:44
#1  __pthread_kill_internal () at pthread_kill.c:89
#2  __GI_raise (sig=6) at ../sysdeps/posix/raise.c:26
#3  __GI_abort () at abort.c:77
#4  WTFCrashWithInfo () at WTF/Headers/wtf/Assertions.h:1057
#5  WTF::initializeMainThread()::$_0::operator()() const
      at /usr/src/debug/webkitgtk-2.53.91-1.fc45.x86_64/Source/WTF/wtf/MainThread.cpp:47
#6  std::__invoke_impl<...>   at include/c++/16/bits/invoke.h:63
#7  std::__invoke<...>        at include/c++/16/bits/invoke.h:98
#8  std::call_once<...>       at include/c++/16/mutex:916
#9  std::once_flag::_Prepare_execution<...>  at include/c++/16/mutex:849
#10 std::once_flag::_Prepare_execution<...>::__invoke ()  at include/c++/16/mutex:849
#11 __pthread_once_slow () at pthread_once.c:116
#12 WebKit::webkitInitialize()  (libwebkit2gtk-4.1.so.0)
#13 __pthread_once_slow () at pthread_once.c:116
#14 webkit_web_context_class_intern_init  (libwebkit2gtk-4.1.so.0)
#15 g_type_class_get           (libgobject-2.0.so.0)
#16 g_object_new_with_properties (libgobject-2.0.so.0)
#17 g_object_new               (libgobject-2.0.so.0)
#18 createDefaultWebContext    (libwebkit2gtk-4.1.so.0)
#19 g_once_impl                (libglib-2.0.so.0)
#20 Java_org_eclipse_swt_internal_webkit_WebKitGTK_webkit_1web_1context_1get_1default
      (libswt-webkit-gtk-4973r12.so)

Reproducible: Always

Steps to Reproduce:
1. Install Fedora 45 (branched, upgraded from F44 via dnf system-upgrade)
2. Ensure webkit2gtk4.1-2.53.91-1.fc45 is installed
3. Launch any SWT-based Eclipse IDE (tested: Eclipse 4.40 / SWT 3.134.0)
4. Trigger anything that instantiates an SWT Browser widget — javadoc
   tooltip on hover, Help view, internal browser, or the welcome page
Actual Results:
The JVM aborts (SIGABRT). The crash is inside WebKit, in
WTF::initializeMainThread at Source/WTF/wtf/MainThread.cpp:47:

  RELEASE_ASSERT(!isMainThread() || Thread::currentSingleton().uid() == 1);

Analysis of the core shows the crashing thread is LWP 43927 while the
process's original thread (TID == PID) is LWP 43926. WebKit is being
initialized on the SWT/GTK UI thread, which the JVM creates after process
startup, so it can never have uid 1. This appears structural for any JVM
application: SWT always runs GTK on a thread it creates.

Removing webkit2gtk4.1 lets Eclipse start, but every SWT Browser-based
view is then non-functional. Neither state is a working configuration.

Expected Results:
WebKit initializes successfully when a GTK application calls
webkit_web_context_get_default() from its UI thread, as it did with the
Fedora 44 build of the same code.

Additional Information:
Ruled Out:
JVM version — reproduced identically with the bundled JustJ JRE 21.0.12 and with java-25-openjdk 25.0.4.1.1
SELinux — ausearch -m avc -ts recent returns no matches; reproduced with setenforce 0
WebKit rendering options — reproduced with WEBKIT_DISABLE_COMPOSITING_MODE=1 and WEBKIT_DISABLE_DMABUF_RENDERER=1
SWT browser selection — reproduced with -Dorg.eclipse.swt.browser.DefaultType=none (confirmed present in the crashed process's command line)
WebKit version — reproduced on both 2.53.90-1.fc45 and 2.53.91-1.fc45
LD_PRELOAD of libwebkit2gtk-4.1.so.0 — does not change the outcome

Comment 1 mark97753 2026-08-23 17:05:47 UTC
Created attachment 2155468 [details]
gdb backtrace and thread list from core (PID 43926)

Full backtrace plus thread list. Note LWP 43927 (crashing thread) vs LWP 43926 (TID == PID, process main thread).

Comment 2 mark97753 2026-08-23 17:09:13 UTC
Question for the maintainer

Was this RELEASE_ASSERT newly added or newly reachable in the 2.53.x series? The same Eclipse/SWT combination initialized WebKit on the UI thread without issue on Fedora 44. If the invariant is long-standing, something in the surrounding initialization must have changed such that the main thread's uid now comes out != 1 — possibly related to the gcc 16 / libstdc++ 16 call_once and TLS paths visible in frames 6–10.

Versions
webkitgtk4.1          2.53.91-1.fc45
javascriptcoregtk4.1  2.53.91-1.fc45
gtk3                  3.24.52-6.fc45
glib2                 2.89.3-1.fc45
glibc                 2.44-1.fc45
kernel                7.2.0-61.fc45.x86_64

Eclipse 4.40.0.20260604-0652 (Oracle OUAF SDK 25.4), SWT 3.134.0.v20260515-1429, libswt-webkit-gtk-4973r12.so. Desktop: KDE Plasma on Wayland, NVIDIA 610.57.04.

Fedora 45 branched, upgraded from Fedora 44 via dnf system-upgrade on 2026-08-23.

Comment 3 mark97753 2026-08-23 18:39:05 UTC
Also reproduced under the Fedora 44 kernel (7.1.9-200.fc44.x86_64) on the same F45 userspace — kernel is not a factor.

Comment 4 Michael Catanzaro 2026-08-24 01:12:15 UTC
(In reply to mark97753 from comment #2) 
> Was this RELEASE_ASSERT newly added or newly reachable in the 2.53.x series?

It was added in https://commits.webkit.org/314233@main. I see your AI tested a lot of things, but didn't try a 'git blame'. Next time, do that. :P

Only problem is, the assert looks pretty reasonable, so we should understand precisely why Eclipse is hitting it before we change or remove it. I guess Eclipse is somehow creating a WebKit thread before the WebKit main thread... but that seems really weird.

Next step for you: bug report on WebKit Bugzilla. This is not a packaging issue that can be resolved here.

There's some more Eclipse-specific history in https://commits.webkit.org/253010@main and https://commits.webkit.org/253647@main, but I don't think the problem here is the same.

Comment 5 mark97753 2026-08-24 10:28:10 UTC
Ha yah, AI for us dummies I thought was probably more vastly useful than what I could personally provide. Thank you, I'll file the bug.

Comment 6 Michael Catanzaro 2026-09-17 18:29:48 UTC
Did you create an upstream bug report?