Add tests for all DND transfer types

[jonahgraham]

The individual Transfer types had no automatic testing, so this commit provides tests for all the transfer types and ensures copy/paste to external to SWT works too by implementing flavors for all types in the Swing remote clipboard test app.

Part of #2126

[github-actions]

Test Results

  118 files  ± 0    118 suites  ±0   15m 49s ⏱️ + 4m 25s
4 644 tests +41  4 626 ✅ +41  18 💤 ±0  0 ❌ ±0 
  330 runs  ± 0    326 ✅ ± 0   4 💤 ±0  0 ❌ ±0 

Results for commit 2608fe1. ± Comparison against base commit 75f69db.

♻️ This comment has been updated with latest results.

[jonahgraham]

This seems new to me - build fails Linux with:

[INFO] Running org.eclipse.swt.tests.junit.Test_org_eclipse_swt_custom_CCombo
Aborted (core dumped)
[...]
The forked VM terminated without properly saying goodbye. VM crash or System.exit called [...]
Error occurred in starting fork, check output in log

I wonder what I did wrong that caused core to dump here. I see it is failing during CCombo test (IIUC), but no idea what I did to expose this. The master branch was fine, and this PR has failed twice in the same way.

---

Separately, there are expected to be some Windows/macOS fails here because I need to tune the new tests as they are platform dependent.

[jonahgraham]

(not really ready for review - but marked as such so the tests run on Jenkins as I want gtk4 tests to run too)

[jonahgraham]

On Jenkins the build seems to fail in the same spot, there is no Aborted (core dumped) in https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/PR-2672/6/pipeline-overview/ but the rest of the error output is the same. It looks suspiciously like something I am doing in the DND tests setup something to fail later when CCombo tests run. I cannot reproduce this on my machine yet 😢

[jonahgraham]

This is in the crash log:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f11aae99dc0, pid=2069, tid=2070
#
# JRE version: OpenJDK Runtime Environment Temurin-21.0.8+9 (21.0.8+9) (build 21.0.8+9-LTS)
# Java VM: OpenJDK 64-Bit Server VM Temurin-21.0.8+9 (21.0.8+9-LTS, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x9bddc0]  jni_CallLongMethodV+0xa0
#
# 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" (or dumping to /home/jenkins/agent/workspace/eclipse.platform.swt_PR-2672/eclipse.platform.swt/tests/org.eclipse.swt.tests/core.2069)
#
# If you would like to submit a bug report, please visit:
#   https://github.com/adoptium/adoptium-support/issues
#

---------------  S U M M A R Y ------------

Command Line: -Dorg.eclipse.swt.internal.gtk.disablePrinting /home/jenkins/agent/workspace/eclipse.platform.swt_PR-2672/eclipse.platform.swt/tests/org.eclipse.swt.tests/target/surefire/surefirebooter-20251025122012018_3.jar /home/jenkins/agent/workspace/eclipse.platform.swt_PR-2672/eclipse.platform.swt/tests/org.eclipse.swt.tests/target/surefire 2025-10-25T12-20-11_310-jvmRun1 surefire-20251025122012018_1tmp surefire_0-20251025122012018_2tmp

Host: Intel(R) Xeon(R) Silver 4114 CPU @ 2.20GHz, 40 cores, 4G, Ubuntu 24.04.3 LTS
Time: Sat Oct 25 12:21:40 2025 UTC elapsed time: 88.254915 seconds (0d 0h 1m 28s)

---------------  T H R E A D  ---------------

Current thread (0x00007f11a402ba60):  JavaThread "main"             [_thread_in_vm, id=2070, stack(0x00007f11aa2ee000,0x00007f11aa3ee000) (1024K)]

Stack: [0x00007f11aa2ee000,0x00007f11aa3ee000],  sp=0x00007f11aa3e7230,  free space=996k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x9bddc0]  jni_CallLongMethodV+0xa0
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  org.eclipse.swt.internal.gtk3.GTK3.gtk_editable_copy_clipboard(J)V+0
j  org.eclipse.swt.widgets.Text.copy()V+38
j  org.eclipse.swt.custom.CCombo.copy()V+8
j  org.eclipse.swt.tests.junit.Test_org_eclipse_swt_custom_CCombo.test_copy()V+50
J 5792 c1 java.lang.invoke.LambdaForm$DMH+0x00007f1127114400.invokeVirtual(Ljava/lang/Object;Ljava/lang/Object;)V [email protected] (14 bytes) @ 0x00007f118d1ffcfc [0x00007f118d1ff960+0x000000000000039c]

[jonahgraham]

Disabling the CCombo clipboard tests avoids the crash and then the Text clipboard tests that run next pass fine. So its weird.

[jonahgraham]

Woohoo 🤷

I can reproduce on my machine - it only fails with xvfb-run - doing this crashes as described in #2672 (comment)

xvfb-run mvn --batch-mode -V -U -e --threads 1C -DforkCount=1 '-Dnative=gtk.linux.x86_64' -Papi-check -Pjavadoc '-Dtycho.baseline.replace=none' --fail-at-end -DskipNativeTests=false -DfailIfNoTests=false clean verify

running same command on Xtigervnc, Xfce (Xorg???), Xwayland is all ok.

[jonahgraham]

Using this configuration I can reproduce the crash in Eclipse.

xvfb-run --auth-file=/tmp/my_xvfb_auth_file.Xauthority --server-num=50 sleep 1d

Which leads to - the same error I see on the build machine. And it doesn't take too long to get to this point, so I should be able to identify the problem.

[jonahgraham]

If you run just these three tests, in this order you get the crash during test_copy 🤯

• Test_org_eclipse_swt_dnd_ByteArrayTransfer.test_Validate()
• Test_org_eclipse_swt_graphics_ImageLoader.test_bug547529()
• Test_org_eclipse_swt_custom_CCombo.test_copy()

[jonahgraham]

The unique thing about that sequence of steps.

1. Test_org_eclipse_swt_dnd_ByteArrayTransfer.test_Validate() places a custom transfer type on the clipboard
2. Test_org_eclipse_swt_graphics_ImageLoader.test_bug547529 is the only test between 1 and 3 that does Display.dispose()
3. Test_org_eclipse_swt_custom_CCombo.test_copy() tries to access clipboard

The dispose of Display causes dispose of ClipboardProxy which disposes some callbacks associated with the current clipboard. When Text.copy is run the GTK3 implementation eventually tries to call one of those callbacks (clearFunc) to notify the current clipboard owner that it does not own clipboard anymore (see docs or source)

Since the callback is disposed, the run crashes the JVM.

With this information I can both workaround this issue, by clearing the clipboard in teardown so there won't be something to call clearFunc for, and probably make a single reduced test case - fixing the problem is probably trickier, but maybe we can detect it. Update to this PR upcoming, as well as new issue/PR with reduced test case.