libsForQt5.qmltermwidget: Fetch patch to Lomiri's patch series

[OPNA2608]

...to fix a crash in lomiri-terminal-app.

Description of changes

Working towards #99090.

A debugging of this issue can be found here: https://gitlab.com/ubports/development/apps/lomiri-terminal-app/-/issues/104#note_1662252236
I have submitted this to gber/qmltermwidget#1, where it (or a variant of it) should hopefully find its way into the UBports/Lomiri patch series.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
    Tested the tests/terminal-emulators.nix entry for lomiri.lomiri-terminal-app after removing the workaround for this issue there, doesn't crash on shutdown now
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
  Current hardware doesn't have enough RAM for nixpkgs-review. I tested cool-retro-term (unaffected by this, but doesn't hurt I guess) and lomiri.lomiri-terminal-app
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[ghost]

so looking at the patch, other than i am not familiar with the codebase, is that it sets the owner on every call -- seems ideally that would happen just once when the instance is created.

i suppose that this is a read / write object and if there is concurrent access that is gated elsewhere, but if it is supposed to be just read-only (and not returned as const)

QQmlEngine::setObjectOwnership(instance, QQmlEngine::CppOwnership);

as long as that is just writing the same data to the same location without side effects, that seems fine to me.

[OPNA2608]

it sets the owner on every call -- seems ideally that would happen just once when the instance is created.

AFAIU, it does only set it once. colorschememanager_provider is used as a callback for qmlRegisterSingletonType to setup a singleton instance of a type for the QML side to use. The expectation is normally that this callback returns a unique object, which will then be managed by the QML engine & free'd on shutdown. But since this re-uses a global object automagically created by Qt on startup it must be marked as C++-owned so the QML engine doesn't try to free an object that it doesn't own.

I'm not sure how concurrent R/W access is gated, or if that's even necessary, and my patch doesn't really affect that AFAICT. It's just about marking object lifetime & responsibilities, which are currently wrong & cause a SIGABRT with free(): invalid pointer on shutdown.

[ghost]

it sets the owner on every call -- seems ideally that would happen just once when the instance is created.

AFAIU, it does only set it once.

that works for me -- preventing SIGABRT is a definite improvement.

[ghost]

LGTM