Community
Participate
Working Groups
Created attachment 287521 [details] Crash reproducer application I get a SIGSEGV every time I perform the actions instructed by the attached reproducer application. A snippet from the stack trace: > Current thread (0x00007f2d2002ab90): JavaThread "main" [_thread_in_native, id=186030, stack(0x00007f2d25288000,0x00007f2d25388000)] > > Stack: [0x00007f2d25288000,0x00007f2d25388000], sp=0x00007f2d25384c80, free space=1011k > Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [libgtk-3.so.0+0x384a31] > > Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) > J 919 org.eclipse.swt.internal.gtk.GTK.gtk_tree_store_set(JJIII)V (0 bytes) @ 0x00007f2d15d6b3f6 [0x00007f2d15d6b3a0+0x0000000000000056] > J 1089 c2 org.eclipse.swt.widgets.Tree.cellDataProc(JJJJJ)J (485 bytes) @ 0x00007f2d15d819a8 [0x00007f2d15d80bc0+0x0000000000000de8] > J 1075 c2 org.eclipse.swt.widgets.Display.cellDataProc(JJJJJ)J (29 bytes) @ 0x00007f2d15d7d820 [0x00007f2d15d7d6c0+0x0000000000000160] > v ~StubRoutines::call_stub > j org.eclipse.swt.internal.gtk.GTK.gtk_tree_store_clear(J)V+0 > j org.eclipse.swt.widgets.Tree.removeAll()V+46 > j test.Main$1.widgetSelected(Lorg/eclipse/swt/events/SelectionEvent;)V+4 > j org.eclipse.swt.widgets.TypedListener.handleEvent(Lorg/eclipse/swt/widgets/Event;)V+1133 > J 1019 c1 org.eclipse.swt.widgets.EventTable.sendEvent(Lorg/eclipse/swt/widgets/Event;)V (577 bytes) @ 0x00007f2d0ea5c194 [0x00007f2d0ea5bde0+0x00000000000003b4] > J 1058 c2 org.eclipse.swt.widgets.Display.readAndDispatch()Z (90 bytes) @ 0x00007f2d15d7aec0 [0x00007f2d15d7a820+0x00000000000006a0] > j test.Main.main([Ljava/lang/String;)V+189 > v ~StubRoutines::call_stub Some observations: - Simply clicking the button repeatedly, without ever selecting a row doesn't cause a crash. - If, before pressing the button a second time, I scroll through the entire table, the crash doesn't happen, even if I selected a row. - If I make the number of toplevel items smaller (and/or the Table taller), so that all of them fit into the viewport without scrolling, the crash doesn't happen.
Snippet works just fine on RHEL 7.4 / GTK 3.22. Which GTK version do you have?
org.eclipse.swt.internal.gtk.version=3.24.30
BTW, I'm on Fedora 35. A colleague reports that on Ubuntu 20.04 LTS with GTK 3.24.20 it also doesn't crash.
I can't reproduce this crash on Fedora 35 GTK 3.24.30 on Wayland or using GDK_BACKEND=x11.
I'm not sure if it matters, but I'm running the KDE Spin of Fedora. Switching the Plasma session (and the GDK backend in turn) between X11 and Wayland doesn't make a difference. Neither does switching to a different GTK theme (Yaru-dark in my case).
I can reliably reproduce the crash on a freshly installed regular Ubuntu Desktop 21.10 in a VM. With Eclipse 2021-09-R, SWT 4.21, GTK 3.24.30, on Wayland. Seems like it could be a matter of GTK 3.24.20 (no crash) vs. 3.24.30 (crash)?
Alex, do you know where the GTK 3 release notes are? I only see latest 4.5 at https://gitlab.gnome.org/GNOME/gtk/-/releases
The file gtk+-3.24.30.news from https://download.gnome.org/sources/gtk+/3.24/ does mention some GtkTreeView changes. So does the one for 3.24.24, but that looks unrelated.
Here it is https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/NEWS
I've tests Gnome on X11 and Wayland and KDE on X11 and Wayland with gtk3-3.24.30-4.fc35 but wasn't able to reproduce the issue. Is this exactly the same gtk version you have? On crash there should be hs_err_pid*.log file can you attach it here ?
Yes, exactly gtk3-3.24.30-4.fc35 on my main system, and libgtk-3-0 3.24.30-1ubuntu1 in the VM. I have several of those .log files, attaching one now.
Created attachment 287529 [details] A crash log
Created attachment 287530 [details] Screen recording of a crash in the Ubuntu VM Just as proof, and to double-verify the method for reproducing it
(In reply to Attila Török from comment #12) > Created attachment 287529 [details] > A crash log There is a core file mentioned. Could you please run gdb <path to core file> bt and add here the backtrace?
Certainly. I had to fight with apport to even actually get the mentioned core file, but here it is... These are the interesting parts: #8 0x00007f595923eade in VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*) () from /home/default/Downloads/eclipse-java-2021-09-R-linux-gtk-x86_64/eclipse/plugins/org.eclipse.justj.openjdk.hotspot.jre.full.linux.x86_64_16.0.2.v20210721-1149/jre/lib/server/libjvm.so #9 0x00007f59590e83fa in JVM_handle_linux_signal () from /home/default/Downloads/eclipse-java-2021-09-R-linux-gtk-x86_64/eclipse/plugins/org.eclipse.justj.openjdk.hotspot.jre.full.linux.x86_64_16.0.2.v20210721-1149/jre/lib/server/libjvm.so #10 <signal handler called> #11 0x00007f5915ce7a9e in ?? () from /lib/x86_64-linux-gnu/libgtk-3.so.0 #12 0x00007f59153b3c0f in g_closure_invoke () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #13 0x00007f59153cfea6 in ?? () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #14 0x00007f59153d1884 in g_signal_emit_valist () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #15 0x00007f59153d1ad3 in g_signal_emit () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #16 0x00007f5915cd62df in gtk_tree_store_set_valist () from /lib/x86_64-linux-gnu/libgtk-3.so.0 #17 0x00007f5915cd63b8 in gtk_tree_store_set () from /lib/x86_64-linux-gnu/libgtk-3.so.0 #18 0x00007f59161d5ea3 in Java_org_eclipse_swt_internal_gtk_GTK_gtk_1tree_1store_1set__JJIII () from /home/default/.swt/lib/linux/x86_64/libswt-pi3-gtk-4946r21.so #19 0x00007f5941afd333 in ?? () #20 0x00000000ffffffff in ?? () #21 0x00007f59153d0800 in g_signal_emit_valist () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #22 0x00007f5941af59d4 in ?? ()
And this is from my main system, where debuginfod downloaded the debug symbols for all libraries (hence the different Eclipse location): #7 0x00007f1c4061308e in VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*) () at /home/attila/omnetpp-6.0pre14/ide/plugins/org.eclipse.justj.openjdk.hotspot.jre.full.stripped.linux.x86_64_15.0.2.v20210201-0955/jre/lib/server/libjvm.so #8 0x00007f1c403fd71e in JVM_handle_linux_signal () at /home/attila/omnetpp-6.0pre14/ide/plugins/org.eclipse.justj.openjdk.hotspot.jre.full.stripped.linux.x86_64_15.0.2.v20210201-0955/jre/lib/server/libjvm.so #9 0x00007f1c403f09f8 in signalHandler(int, siginfo*, void*) () at /home/attila/omnetpp-6.0pre14/ide/plugins/org.eclipse.justj.openjdk.hotspot.jre.full.stripped.linux.x86_64_15.0.2.v20210201-0955/jre/lib/server/libjvm.so #10 0x00007f1c40a95760 in <signal handler called> () at /lib64/libc.so.6 #11 0x00007f1c0464aa31 in _gtk_cell_accessible_update_cache (emit_signal=1, cell=0x7f1c38d3a920) at a11y/gtkcellaccessible.c:532 #12 _gtk_tree_view_accessible_changed (node=0x7f1c3935d240, tree=0x7f1c38b14890, treeview=0x7f1c38b5d790) at a11y/gtktreeviewaccessible.c:1776 #13 gtk_tree_view_row_changed (model=0x7f1c3f7cf970, path=0x7f1c39059910, iter=<optimized out>, data=0x7f1c38b5d790) at /usr/src/debug/gtk3-3.24.30-4.fc35.x86_64/gtk/gtktreeview.c:9031 #17 0x00007f1be22bfb23 in <emit signal ??? on instance ???> (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at ../gobject/gsignal.c:3553 #14 0x00007f1be22a1c2f in g_closure_invoke (closure=0x7f1c3933ed80, return_value=0x0, n_param_values=3, param_values=0x7f1c3f7cfb70, invocation_hint=0x7f1c3f7cfaf0) at ../gobject/gclosure.c:830 #15 0x00007f1be22be046 in signal_emit_unlocked_R (node=node@entry=0x7f1c3889e000, detail=detail@entry=0, instance=instance@entry=0x7f1c3933b850, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7f1c3f7cfb70) at ../gobject/gsignal.c:3742 #16 0x00007f1be22bf90a in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7f1c3f7cfd50) at ../gobject/gsignal.c:3497 #18 0x00007f1c04639e6f in gtk_tree_store_set_valist (tree_store=0x7f1c3933b850, iter=0x7f1c387b5960, var_args=var_args@entry=0x7f1c3f7cfe70) at /usr/src/debug/gtk3-3.24.30-4.fc35.x86_64/gtk/gtktreestore.c:1161 #19 0x00007f1c04639f48 in gtk_tree_store_set (tree_store=<optimized out>, iter=<optimized out>) at /usr/src/debug/gtk3-3.24.30-4.fc35.x86_64/gtk/gtktreestore.c:1190 #20 0x00007f1c04b3aea3 in Java_org_eclipse_swt_internal_gtk_GTK_gtk_1tree_1store_1set__JJIII () at /home/attila/.swt/lib/linux/x86_64/libswt-pi3-gtk-4946r21.so #21 0x00007f1c29014ee3 in () #22 0x00007f1cffffffff in () #23 0x00007f1c400a45a8 in jni_ReleaseIntArrayElements () at /home/attila/omnetpp-6.0pre14/ide/plugins/org.eclipse.justj.openjdk.hotspot.jre.full.stripped.linux.x86_64_15.0.2.v20210201-0955/jre/lib/server/libjvm.so #24 0x00007f1c298bc0b4 in () #25 0x000000062a4ea8e0 in ()
@Alexandr M.: do you have time/interest to check the backtrace in comment 16?
Created attachment 287534 [details] Failed attempt to reproduce on Ubuntu 21.04 Unfortunately I can't reproduce with the provided snippet on Ubuntu 21.04 (GTK 3.24.25). I also tried with additional memory error checking software. I also tried with GTK 3.24.30 (compiled it from sources). See my screencast for example of what I've been doing. This crash, judging from the stack, is similar to Bug 573932, but I can't see any problems in code this time. Could you please also hs_err_pid.log files, from different machines if possible? According to your screencast, it's located there: /home/default/eclipse-workspace/swt-bug/
I have installed Ubuntu 21.10 VM and it's also NOT reproducible there. Weird. Any ideas?
Have you checked the "download updates while installing" option? I have. And is that also on GTK 3.24.30? Because I noticed that in the backtrace given by gdb, there are a few accessibility-related functions, and the changelog for GTK 3.24.30 is what mentioned some a11y changes in GtkTreeView. I can get back to you with a few more hs_err_*.log files in a couple hours. Also, if it comes to that, I can also just send you the whole Ubuntu 21.10 VM that I can reproduce it in.
Created attachment 287535 [details] Java crash log 1 from machine B (Eclipse) As requested, this is another hs_err_*.log file, from a different machine, running not the minimal example application, but a whole Eclipse product - this was the original place where the crash surfaced.
Created attachment 287536 [details] Java crash log 2 from machine B (Eclipse)
In at least one case, Tree.removeAll() is not on the stack, but gtk_tree_store_set still seems to be a common point in all cases.
> Have you checked the "download updates while installing" option? Yes, and I also did `sudo apt update` + `sudo apt upgrade` just in case. > And is that also on GTK 3.24.30? Yes, I am using the same GTK version as you: $ dpkg -l libgtk-3-0 ii libgtk-3-0:amd64 3.24.30-1ubuntu1 $ pmap 4837 | grep gtk 00007faff43ec000 528K r---- /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2404.26 00007faff4470000 3596K r-x-- /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2404.26 00007faff47f3000 4136K r---- /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2404.26 00007faff4bfd000 4K ----- /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2404.26 00007faff4bfe000 64K r---- /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2404.26 00007faff4c0e000 8K rw--- /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2404.26 ---- I noticed that you're using OpenJDK 15. Where did you get it? To my understanding, Ubuntu offers {8, 11, 16, 17, 18}, but not 15. I have now tried 11 and 16, and still can't reproduce. The other thing I noticed is that 'hs_err_pid.log' files you have attached are for Eclipse itself, and yes, these don't have 'Tree.removeAll()' on stack. Could you please also attach crash logs from the snippet?
JRE 15 is from the Eclipse JustJ project. We had to revert from JRE 16 due to an unrelated compatibility issue with Py4J...
Created attachment 287539 [details] Java crash log, reproducer snippet, JRE 11, machine C I tried on yet-another machine: Fedora 35, KDE, X11, this time with JRE 11, again gtk3-3.24.30-4.fc35 Similarly reliably reproducible. Attached crash log.
Bug 563393 also looks quite similar.
I can reproduce on Fedora 35 with SWT 4946r21, but NOT with latest SWT. I will now find which commit fixed it...
Fixed with my patch: Bug 575787 - [GTK] Drop fixAccessibility() hack in Table, Tree Sounds like I had a very timely intuition to clean up some old hacks :) The problem is NOT reproducible with GTK 3.24.25, but is reproducible with 3.24.30.
@Andrey thanks for bringing this to my attention. I'm generally interested in native crashes. Don't hesitate to CC me if you find more of these.
Ooh, I'm so glad! Both for the repro and the fix! Which SWT release is this going to be in? 4.22 perhaps?
Yes, it should be part of 4.22 Thanks for a detailed bug report!
Thanks for all your work on this Alexandr, Tree/Table code can be quite nasty so your fixes go a long way!
(In reply to Alexandr Miloslavskiy from comment #29) > Fixed with my patch: > Bug 575787 - [GTK] Drop fixAccessibility() hack in Table, Tree I assume this is only this patch: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/185276 or do you mean, previous one is also required: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/185275 ? > Sounds like I had a very timely intuition to clean up some old hacks :) Good intuition :-)
(In reply to Alexandr Miloslavskiy from comment #32) > Yes, it should be part of 4.22 > Thanks for a detailed bug report! Good to hear, thank you! And until 4.22 comes around, could someone maybe give me some hints on a Java-level workaround for this crash on SWT 4.21 and GTK 3.24.30? I might be able to figure something out, like "emulating" scrolling through the entire tree (see observations in original description), essentially turning it somewhat "less virtual"... But there might be a better way?
(In reply to Attila Török from comment #35) > (In reply to Alexandr Miloslavskiy from comment #32) > > Yes, it should be part of 4.22 > > Thanks for a detailed bug report! > > Good to hear, thank you! > And until 4.22 comes around, could someone maybe give me some hints on a > Java-level workaround for this crash on SWT 4.21 and GTK 3.24.30? > I might be able to figure something out, like "emulating" scrolling through > the entire tree (see observations in original description), essentially > turning it somewhat "less virtual"... > But there might be a better way? There is no easy Java level workaround you would have to recompile SWT with this patch. It is probably easiest to use latest I-build from https://download.eclipse.org/eclipse/downloads/index.html . RC1 is supposed to get out tomorrow so not much changes (hopefully none) should happen from that point to release.
(In reply to Andrey Loskutov from comment #34) > I assume this is only this patch: > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/185276 Yes, just this patch should be sufficient.
(In reply to Alexandr Miloslavskiy from comment #37) > (In reply to Andrey Loskutov from comment #34) > > I assume this is only this patch: > > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/185276 > > Yes, just this patch should be sufficient. Thanks, good to know if I would need to backport that to our 4.21 platform for RHEL 9.
I think that you won't need to, because the crash only seems to occur after GTK 3.24.25
(In reply to Alexandr Miloslavskiy from comment #39) > I think that you won't need to, because the crash only seems to occur after > GTK 3.24.25 I honestly have no idea which GTK is in RHEL9, we don't have it yet in the lab, just heard about plans to move our products from 7.4 straight forward to RHEL 9.
