Access Violation When Renaming A Component

[antitu]

When renaming a component in the Hierarchy list, clicking away from the rename field will generate an Access Violation. The console output shows:
(castle-editor:13893): GLib-GObject-CRITICAL **: 00:09:17.444: ../glib/gobject/gsignal.c:1285: no emission of signal "button-release-event" to stop for instance '0x6b349b0'

System Details:
OS - Manjaro x64
Kernel - 6.4.6-3-rt8

Steps to reproduce:

1. In the Castle Editor, click on a component, then click again to rename it.
2. Click on another component in the list.
3. An Access Violation window will appear.

Screenshots

Renaming A Component

Access Violation

[michaliskambi]

Thank for you for reporting!

Quick investigation now shows the crash is somewhere deep inside GTK2 widgetset implementation in LCL. I wasn't able to pinpoint it better now. Lazarus debugger doesn't show anything useful (goes to assembler view), VS Code debugger shows that GTK2 routine g_type_check_instance_is_a got invalid pointer, maybe because something higher-up got nil pointer:

When CGE editor is recompiled to use Qt5 widgetset on Linux, everything works OK.

I've been wondering about switching CGE editor widgetset to Qt5 already, as we already had some crashes in GTK2 with ugly workarounds (but at least the previous ones had a workaround).

The main downside of using Qt5 will be that users need to install libqt5pas library (on Debian or Ubuntu: libqt5pas1 package), which probably most users don't have. The upside is that we completely avoid GTK2-specifc bugs, and we avoid using deprecated GTK2 for editor... See also recent talk about CGE on Debian mailing list, my message: https://alioth-lists.debian.net/pipermail/pkg-pascal-devel/Week-of-Mon-20230925/004933.html .

I'll see how to deal with this:

• Maybe this is another argument to switch CGE editor to Qt5 widgetset. This is a critical bug, it is better to require libqt5pas dependency than to have a crash in the middle of editing.

• We definitely should fix or workaround GTK2 bug, even if GTK2 will not be the default widgetset. Or we will have to say "GTK2 widgetset is uinsupported" and block compiling CGE editor with it. (As we do with GTK3 widgetset now, which is very unstable.)

[bbrtj]

This was getting increasingly annoying lately so I'm happy it's as simple as compiling with qt5. I was a bit wary at first because of #391, but it seems it's all good and fixed now. It also resolves my other problem from #426. Seems like a single dependency is not too high of a price for all these issues resolved, but it's good to have an alternative as well just in case.

[michaliskambi]

I'm talking with Jenkins now to provide automatic build of CGE editor with Qt5 widgetset in our official downloads on https://castle-engine.io/download . For start, we'll have castle-editor-qt5 binary alongside (GTK 2) castle-editor.

The old issue #391 should no longer pose any problem, as my fix https://gitlab.com/freepascal.org/lazarus/lazarus/-/merge_requests/95 was merged to Lazarus and it's available since Lazarus 2.2.4 onward. @bbrtj Though I see your #546 -- I'll investigate it soon, thank you for testing qt5 version!

[michaliskambi]

FYI, I retested this issue with latest FPC + Lazarus from the GitLab main branches, hoping for improvements ( @and3md mentioned that there were some GTK2 fixes). Alas, the bug is still there (with GTK2 widgetset, that is).

[and3md]

I tried to reproduce this on Linux Mint 21.1 Cinnamon using fpc/lazarus fixes branch and master. But it looks like it works without any problems for me (maybe I'm lucky one but never had this error). Maybe it depends on the graphical environment?

To be precise, I also have these warnings (no emission of signal "button-release-event" ) in the console.

[michaliskambi]

Notes about things done/tested around this:

• I retested today with latest FPC and Lazarus from GitLab (Lazarus version reported now 3.99), as @and3md mentioned a few GTK2 improvements happened in LCL. The error is still there, unfortunately. It doesn't reproduce 100% times, but after a few tries it is reproducible. A new project, from "3D FPS game" template, and clicking + renaming between SceneEnemy* instances -> reproduce it after a few tries.

• We are going forward with testing Qt5 version of the editor. CGE binaries include castle-editor-qt5 alongside castle-editor now since some time.

• While this bug is fixed by Qt5 version, it's not a straightforward change to "just give users Qt5 CGE editor by default", as

  • [Editor] Viewport becomes unresponsive after previewing a model #546
  • Raspberry Pi 32-bit (Arm) Qt5 binaries don't link with libqt5pas: https://github.com/castle-engine/castle-engine/blob/master/tools/internal/pack_release/pack_release.sh#L334
  • Lazarus 3.0 requires a newer version of libqt5pas, making it more risky -- some users may have libqt5pas, but in older version, and then CGE editor would crash for them. See Very Important Notice about setup-lazarus #559 .
  • And there remains the problem that I mentioned earlier -- many users will just not have libqt5pas installed at all, making CGE editor crash for them, and to debug they'd have to run from console to see the link error message mention libqt5pas.

• All in all, it seems the only way to really deploy Qt5 editor by default, in a way that doesn't cause friction for new users ("I just run the editor and it crashed!") would be to use Snap or Flatpak. To package CGE along with libqt5pas and other libraries, in versions that are tested to work together. So progress on this -> practically requires first to progress on Snap, which I started long time ago, see https://castle-engine.io/wp/2022/05/01/editor-improvements-ui-improvements-in-progress-snap-packages-linux-packages-on-any-distribution-testing-lights-and-3d-models-from-sketchfab/ .

[michaliskambi]

We are going forward with testing Qt5 version of the editor. CGE binaries include castle-editor-qt5 alongside castle-editor now since some time.

Unfortunately today I had to disable building castle-editor-qt5 -- because Lazarus 3.2 Qt5 bindings are not compatible with libqt5pas present in latest Ubuntu stable ( see https://forum.lazarus.freepascal.org/index.php/topic,65619.msg500216.html#msg500216 and also note about it on https://github.com/gcarreno/setup-lazarus?tab=readme-ov-file ). We could update libqt5pas in our Docker image, but the resulting binary would crash on users' systems (if they don't have updated libqt5pas). Unfortunately, this issue (need to have right version of libqt5pas in order to make binaries compiled with Qt5 backend work) makes the LCL Qt5 binding problematic.

At this point I think Snap or Flatpak, as mentioned above, are the only hope to distribute binaries compiled with LCL Qt5 backend reasonably (so that users are not surprised with crashes).