Bug 322394 – REGRESSION(317619@main): RELEASE_ASSERT in initializeMainThread aborts Eclipse/SWT applications

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

Created attachment 481135 [details]
gdb backtrace and thread list from core (PID 43926)

## Description

The `RELEASE_ASSERT` added in 314233@main aborts any Eclipse IDE using the SWT
Browser widget on WebKitGTK. Reported downstream as Fedora bug 2521651; Michael
Catanzaro identified the introducing commit and asked that it be raised here, as
the assert is not a packaging issue.

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

Context:

```c++
static std::once_flag initializeKey;
std::call_once(initializeKey, [] {
    initialize();
    initializeMainThreadPlatform();
    RunLoop::initializeMain();
    RELEASE_ASSERT(!isMainThread() || Thread::currentSingleton().uid() == 1);
});
```

### 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 Source/WTF/wtf/MainThread.cpp:47
#6  std::__invoke_impl<...>                    (libstdc++ 16)
#7  std::__invoke<...>                         (libstdc++ 16)
#8  std::call_once<...>                        (libstdc++ 16)
#9  std::once_flag::_Prepare_execution<...>    (libstdc++ 16)
#10 std::once_flag::_Prepare_execution<...>::__invoke ()
#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)
```

### Thread state at the abort

`info threads` on the core shows the abort occurs on **LWP 43927**, while the
process's original thread — the one whose TID equals the PID — is **LWP 43926**:

```
* 1    Thread 0x7ff5bf3ff6c0 (LWP 43927)   <-- aborting thread
  9    Thread 0x7ff5c0a5c740 (LWP 43926)   <-- TID == PID
```

83 threads were live at the time of the abort (JVM GC, JIT compiler, and worker
threads, plus the SWT/GTK UI thread).

SWT runs the GTK main loop on a thread the JVM creates during startup, never on
the process's original thread. `webkit_web_context_get_default()` is therefore
always called from a non-original thread in any Eclipse/SWT application.
`isMainThread()` returns true because WebKit records the first caller, but
`Thread::currentSingleton().uid()` is not 1.

Michael Catanzaro's read on the downstream report was that Eclipse may be
creating a WebKit thread before the WebKit main thread, which he noted seemed
unusual — that may be a more precise characterization than the above, and I have
not been able to determine which is correct.

### Impact

This affects every Eclipse IDE distribution on Linux that uses the SWT Browser
widget — the internal browser, javadoc hover rendering, the welcome page, and any
plugin that embeds HTML content. Reproduced with Eclipse 4.40 / SWT 3.134.0.

Uninstalling webkit2gtk lets Eclipse launch, but every Browser-based view is then
non-functional. Neither state is a usable configuration.

### Ruled out

- **JVM version** — reproduced with OpenJDK 21.0.12 and 25.0.4
- **Kernel** — reproduced under both 7.2.0-61.fc45 and 7.1.9-200.fc44 on the same
  userspace
- **SELinux** — no AVCs; reproduced with SELinux permissive
- **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`
- **WebKit version** — reproduced on 2.53.90 and 2.53.91
- **LD_PRELOAD of libwebkit2gtk-4.1.so.0** — no change

### Environment

```
webkitgtk            2.53.91
gtk3                 3.24.52
glib2                2.89.3
glibc                2.44
gcc / libstdc++      16.2.1
kernel               7.2.0-61.fc45.x86_64
distribution         Fedora 45 (branched pre-release)
```

Eclipse 4.40.0.20260604-0652, SWT 3.134.0.v20260515-1429,
`libswt-webkit-gtk-4973r12.so`. KDE Plasma on Wayland, NVIDIA 610.57.04.

The same Eclipse installation worked on Fedora 44 with that release's WebKitGTK
build.

### References

- Downstream: https://bugzilla.redhat.com/show_bug.cgi?id=2521651
- Introducing commit: https://commits.webkit.org/314233@main
- Prior Eclipse-related: https://commits.webkit.org/253010@main and
  https://commits.webkit.org/253647@main

[Michael Catanzaro]

At first I thought the mistake here was assuming the WebKit main thread is the same as the OS main thread, which is not true in Java apps like Eclipse where the JVM reserves the OS main thread for itself and all application code runs on a different thread. (See the warning comment about this in MainThreadGeneric.cpp.) But no, looking at this commit, I don't see the problem. It's just a simple counter. Should be fine. I guess we have to debug it to figure out what is wrong. That said, although I don't understand the problem, it's probably going to be _somehow_ related to the fact that WebKit main thread doesn't match the OS main thread.

[Adrian Perez]

(In reply to Michael Catanzaro from comment #1)
> At first I thought the mistake here was assuming the WebKit main thread is
> the same as the OS main thread, which is not true in Java apps like Eclipse
> where the JVM reserves the OS main thread for itself and all application
> code runs on a different thread. (See the warning comment about this in
> MainThreadGeneric.cpp.) But no, looking at this commit, I don't see the
> problem. It's just a simple counter. Should be fine. I guess we have to
> debug it to figure out what is wrong. That said, although I don't understand
> the problem, it's probably going to be _somehow_ related to the fact that
> WebKit main thread doesn't match the OS main thread.

I think the actual regression is 317619@main - note how this commit adds a
check that compares “gettid()==getpid()”. We actually have a similar issue
on Android and we are currently workarounding it:

  https://github.com/Igalia/wpe-android-cerbero/blob/b2e4a0a9be6dcabdd918c49386ce66e46b877968/recipes/wpewebkit/0001-Android-Keep-order-based-main-thread-uid-for-the-au.patch

[Adrian Perez]

(In reply to Adrian Perez from comment #2)
 
> I think the actual regression is 317619@main - note how this commit adds a
> check that compares “gettid()==getpid()”. We actually have a similar issue
> on Android and we are currently workarounding it:
>  
> https://github.com/Igalia/wpe-android-cerbero/blob/
> b2e4a0a9be6dcabdd918c49386ce66e46b877968/recipes/wpewebkit/0001-Android-Keep-
> order-based-main-thread-uid-for-the-au.patch

FWIW, this also means that making the first WebKit API call in a non-main
thread and pushing its GMainContext as the active (to have a working GMainLoop)
on the secondary thread no longer works. It used to be possible to do that, as
long as all the API calls were done always from the same thread, the “WebKit
main thread” did not need to be the same as the process main thread -- this
was used along the years in a few oddball WPE embedding scenarios and it would
be good to bring it back, fixing the Android and SWT/Java use cases while at it.

[Michael Catanzaro]

OK, that makes more sense. We should revert 317619@main.

FYI, quick note you probably already know. 2.54.0 still reproduces the error.

[Alexander Kurtakov]

Is the revert done and is 2.54.1 planned for this ? As this starts getting used in the wild it generates more and more problems. https://github.com/flathub/org.eclipse.Java/issues/143 https://bodhi.fedoraproject.org/updates/FEDORA-2026-164300cb22

If 2.54.1 doesn't land before the F45 final freeze, would carrying the revert as a downstream patch in the Fedora package be an option?

[Michael Catanzaro]

I'll propose a pull request here imminently, and do new Fedora and GNOME builds.

[Michael Catanzaro]

Pull request: https://github.com/WebKit/WebKit/pull/74512

[Alexander Kurtakov]

Thank you !

[EWS]

Committed 321625@main (b34e745e23cd): <https://commits.webkit.org/321625@main>

Reviewed commits have been landed. Closing PR #74512 and removing active labels.

[EWS]

Committed 317695.353@webkitglib/2.54 (e61ab5964b23): <https://commits.webkit.org/317695.353@webkitglib/2.54>

Reviewed commits have been landed. Closing PR #74742 and removing active labels.